Software project management: Why the changes & challenges are bigger than you think

The original article was published in LinkedIn (https://goo.gl/dmiatb)

.

If Agile software development questioned the existence of project managers, technology advancements are fast digging the grave.

The landscape of software project management* has changed rapidly over the last few years. This is mainly due to many organizations adapting Agile software development frameworks and technology is advancing at an exponential pace.

These factors demand that software project managers change the way they have been thought & practiced for many decades.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change — Charles Darwin**

 

 

Agile teams do not require a project manager, theoretically!

Why?

1. An Agile team is cross functional and self-organizing. It has the required skills to develop the product and also members get organized around the tasks. Thus it does not require a person to “manage” or to dictate what to do each day.
2. There is no big upfront planning in an Agile project. That is because Agile teams value “responding to change over following a plan”. Further there is no need to painstakingly monitor how much % is completed each day. And it is not possible to compute scheduled or budget variances.

The basic project management activities such as planning, executing, monitoring & controlling are not required for an Agile team in its traditional form.

So what does an Agile team require?

An Agile team needs a problem solver, a leader but not a manager. Agile teams are good at solving technical problems. But they need someone to lead/guide them, when they face complex non-technical problems.

For example, they need “a person” to work with the Product Owner (PO) when the requirements are not clear. In most cases, the PO is busy and “that person” needs to find a solution which works both for the PO and the team.

In another example, a team faces frequent production bugs & user complaints. The team needs a person to help mitigate the situation and solve the problem.

The closest person to fulfill these demands is a project manager who is skillful in solving complex problems.

The must have skills for “today’s project managers” are “Understanding, & Solving complex problems”

The exponential advancements of technology

Technology today is advancing rapidly but software related technologies are advancing at an exponential pace.

It is said that if the average car had advanced as quickly as the computer over the last 35 years, cars would get 3,666,652 miles per gallon and cost less than $5,000 in 2017! 

These advancements are changing how a project manager works. A software project manager must face two types of advancing technologies. One is software development technologies & second is general technology advancements such as AI, BOTs, IoT, etc.

1. Impact from software development technologies

It’s difficult for project managers to keep up with advancing software development technologies when software engineers themselves struggle to cope with it.

Many advanced tools enter the market daily  creating a complex web of tools. For example you can use NuGet to share code, Docker to automate the delivery. In fact a tool can be found for every sphere  of software development.

Gone are the days where the source code is compiled & manually zipped to a CD for transport. Now it is an era of continuous deployment where production warm ups happen in the production staging slot.

Not only tools, many software development concepts itself are hard to understand. Object Orientation was difficult enough but now things are extremely complex. I took this example from “WebAssembly”

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications

https://webassembly.org/

Although written in English, the description is incomprehensible. 

Complex technologies, tools & concepts create complications for software teams. A “Project manager” should have an in-depth knowledge to comprehend technical concepts to lead & guide the team to resolve  these problems.

A few examples:

1. The build breaks and the team says that it is due to a missing NPM package. If you’re a non-technical project manager, you have no clue about what a  NPM package is or why it is needed in the first place.
2. In a bug triage, the team says the bug is caused by a wrong “dependency injection” — A non-technical project manager may wonder about the injection they are referring to.

A project manager should be knowledgeable in these technologies unlike  in the past, where it was only required to monitor the project plan once it is created.

2. Impact from general technologies

General technologies refer to technologies & products available for general use such as IoT, GPS, AI, BOT, AR, VR, Nano technology, etc.

In the past, new technology was easily understood and converted to a business product. Today, business people struggle to understand these technological advancements to make products out of them.

For example, when the World Wide Web launched, it did not require much brain power to understand the potential business uses of the Web. It was the same when James Watt invented the steam engine and Johannes Gutenberg invented the printing press & somebody invented the wheel.

But today’s technological advancements are so complex that it is virtually impossible for a non Ph.D. holder to understand the business use of it.

For example, AI is now readily available. We hear amazing stories on how AI is used to enhance products, lives, etc.

If you are the PO of a system to track train schedules against the actual arrival times; how do you make use of AI to create a better product? Although it looks simple, it’s not easy unless you have a good understanding of AI concepts & technology. Same goes for “Digital Twins”, BOT, AR, VR, and the list goes on & on. 

The responsibility of mapping technology to possible product/business cases has been delegated to  project managers. This requires him/her to have a good understanding of general technologies.

Futher, Technologies today are creating new economies  for them. For example, the concept of API economy is created based on the technical concept of Application Programming Interface.

The message is simple, if you are a software project manager today, you need to stay on top of the technology game.

Summary

Agile & technological advancements have turned the software project management profession upside down.

• Technological advancements have converted problems from business problems to technical problems (making it difficult for a non-technical project manager to solve).
• The adaptation of Agile software development methodologies has  transformed project managers from managing tasks to become problem solvers.

If you are project manager, embrace the change now! Sharpen your problem solving skills & master the technology.

How the future would look like

It’s difficult to predict the outlook for  project management. Project managers may have to manage well knowledgeable teams spread across the globe.

• Automation will increase and some teams may code for BOTs  The software products will be much more complex than ever
• The project manager role will diminish giving rise to role of the project leader
• Project managers could be  replaced by a “project management bot”

Foot notes

* Mainly these challenges are for  project managers in the IT sector. Project managers from other sectors is less pressured by these factors.

** There are debates about whether this quote was actually made by Charles Darwin.

Refer the following link for  a good discussion regarding why Agile project management exists even though there are no project managers in Agile teams.

https://www.linkedin.com/pulse/myth-agile-project-manager-anthony-mersino/

Homogeneous & heterogeneous queues – Why it is important in software engineering

Photo credit

From very early age, software engineering has been borrowing heavily from manufacturing industry. We as software professionals has learned a lot from manufacturing systems/concepts such as TPS. No doubt, this has helped a great extent to the success of software engineering profession.

But there is one fundamental issue with borrowing blindly from manufacturing. That is manufacturing queues and software development queues are fundamentally different.

Do we have queues in software engineering???

Queue in this context is the line up of work to be completed. In software engineering, our queues are  sprint or product backlog. In manufacturing, queues are the jobs to be performed in a production line.

Manufacturing systems

All (almost) the manufacturing systems are based on “homogeneous queues“. What that means is that each piece of work (job) produced is similar or homogeneous. For example consider a Toyota factory. There will be multiple production lines but one line can produce only one type of vehicle at a time. If the line required to produce another type of vehicle, a considerable downtime is required to for the change.

Software development systems

In software engineering, we can equate a “production line” to the software team and queue to the sprint/product backlog.

Software development teams are never get similar (or homogeneous) type of work.  The first user story (or task) is totally different from the second user story. Therefore the software development queues are “heterogeneous queues” as one task is different from another.

What does this mean? Why this difference is important?

This simple difference in queues makes the DIRECT application of some of manufacturing concepts such as six sigma to software engineering is fundamentally flawed. The concepts which work in homogeneous queues do not necessarily work in heterogeneous queues.

For example, six sigma relies on the variance to identify problems in the system. Variance can only be tracked when the work is repetitive. I.e. when somebody produces the same thing over and over in the same way. We never get this repetition in software development.

If Toyota produces the software in their factory;

Imagine a situation where Toyota has been asked to produce software in their production line.

Photo credit

Engineers will set up the production line for story 1 – Let’s say to develop “User creation” feature. We will have BA workstation specifying the requirements, to be passed to UX workstation to produce prototype, etc. Finally it goes to deployment slot after passing QA.

When the second story (This is a bug to fix in “Global search”) comes to first workstation, that workstation requires a total change of set up. This require downtime for change of set up.

With this amount of variability, most of the manufacturing concepts/tools will be  ineffective.

Conclusion

One needs to be careful and understand this fundamental difference before directly applying manufacturing concepts & tools to software development.

Many misses this important difference between the types of queues which results in pressurizing development teams to deliver software like cars coming out of Toyota production line.

Obviously if the software teams are asked to develop same task over and over again, there will not be any problems

A big cautionary note

A big cautionary note here is that this does not mean that there is no use of adopting concepts from manufacturing or every manufacturing concept is not valid. For example lean concepts such as “inventory as a waste”, “eliminating waste”, etc. are fundamentals and they are still valid fully in software engineering.

My argument here is that as software professionals, we should not blindly adopt ALL the manufacturing concepts in to software development.

Importance of controlled failures

We try to avoid failures as much as possible. But there are certain situations where failures can be beneficial.

For example take a situation where things are not going according to the best possible path but it it is beyond your control to take it back to the correct path. There are few alternatives in such situations.

1. One option is to fight all out and try to get it back to the track.
2. Second option is to let it go & brace for the disaster.
3. The third option is to led the way towards a small & controlled failure.

The purpose of this discussion is to explore the third option. First let’s look at the first & second options. If you use the first option & fight with all guns blazing, it would require significant amount of energy and time. After all it may be that you are fighting a losing war.The second option can lead to a total disaster & the chance of revival can be slim.  

What is a “Controlled failure”?

If you look at the third option next, there are many advantages. My definition of controlled failure is that you let certain variables to fail. Those variables are carefully selected as well as limited.

For example consider a situation where a project team is pushed to deliver under unrealistic deadlines over and over. You are trying to explain to the decision makers about the risk but you hear back every-time “our customers demands it and without meeting those demands company will not survive“. There are many variables to this situation. Examples are “Code quality”, “Functional quality”, “Developer burnout”, “Penalty of missed deadlines”, etc.

So in a controlled failure you open only the cards (variables) you want to play. For example it can be that you select the “Code quality” variable and let a internal deadline to be missed. (Normal option would be to ask the developers to work in another weekend). This can lead to decision makers to realize the importance of adjusting unrealistic deadlines and start working on them. 

The importance

The important aspect of controlled failure is the word “Controlled“. The failure should be such that it does not lead to significant loss and should be possible to control the situation through non-failed variables.

Some further examples for situation where controlled failure may help

1. The request to improve code quality being ignored for a period of time
2. Request for full regression cycle being ignored
3. Certain teams are not preparing for the sprint demo & review & come up with all the excuses
4. In personal life example, kids are ignoring the instruction to go to bed early

The natural tendency of  a leader is to work with the situation and get it back to track. It takes some considerable energy and situations where there are multiple of such scenarios. It requires leader’s heroic effort & it is not a sustainable strategy.

So setting up a controlled fire can help the situation!

For example connecting to above situations

1. Let the next change request to over-run (than working late to finish on time) due to brittle code
2. Let the staging release (before the production release) to have bugs which are noticed by the customer
3. Let an important demo to fail
4. Let the kids to take their own time to go to bed but get them to wake up exactly to the time you want next day

Concluding thoughts

Failures are good on long run if you learn the lesson out of it. A controlled failure will help to learn the lesson and “Control failures” are an important tool in management.

Learning organization & agile software development

Unfortunately most of the organizations do suffer from many learning disabilities. According to Peter Senge, one good example is “enemy is out there“. What it means is that when things fails, organizations find outside thing(s) to blame. For example when sales are lower, companies blame it to the current economic conditions (outside factor) over inefficient selling process (internal factor). Making the sales process efficient could have still yielded more results at the given economic situation. The enemy out there factor limits opportunity to correct the selling process. In generic terms these learning disabilities limits the “opportunity to learn“.

We need to overcome these learning disabilities to truly find the organization that learn!

The concept of “Learning organization” is an emerging concept and it will take time to mature. But the potential of what it offers is promising to explore further. Learning organization is just a term and there is not much value in looking at the definition. What is interesting is to explore the five discipline of a learning organization. Therefore a good definition for the learning organization is an organization that recognizes and practices the following five disciplines.

Note: The discipline here means an area of practice. For example psychology is a discipline so as quantum physics.

Disciplines of a learning organization

1. Systems thinking: Ability to see the whole
2. Personal mastery: The process of life long learning
3. Shared vision: A vision that shared & committed by everybody
4. Mental model: Generalized & assumed view of how the world works
5. Team learning: The process of developing  the ability to create the desired results as a team

What is in it for us?

What it store for us is the simple fact that these disciplines touches the heart of agility. Agile software development is based on empiricism and therefore does not offer a consistent framework for practice. The learning organization disciplines provides a good foundation to truly practice agile software development. In other words agile movement guides us on what we need to do and learning organizations disciplines provides ways to how to practice. 

Let’s explore how it works;

Systems thinking

What systems thinking tells us is to take a holistic approach rather than a component or event oriented view. The second important fact is that we are just part of the system & components in the system regularly exchange feedback. System archetypes provides a structure to understand the systems in operation and how to take the best view. In summary it is the system structure that causes its behavior. A good read on systems thinking can be found here. http://www.thwink.org/sustain/glossary/SystemsThinking.htm

If you think further on this line, you will realize that whole Agile movement is all about taking the systems thinking view.

In prior agile era, we had many phase gates and we had different teams such as business analysis, designers/architects, developers, etc. to perform a single operation of software development. At that time the whole software engineering was a disintegrated & event driven operation.

What agile movement brought in to software engineering was the systems thinking. No longer we have separate events like specification sign-offs, etc. Now we have same team performing different components in software engineering. Today we optimize & find solutions to the whole. For example we invite business people for the retrospectives and to demos. We optimize the feedback mechanisms and increases the frequency of feedback to single iteration. So the agile movement changed the whole structure of the software engineering thus creating a total different behavior. Simply we as agilists ride on top the systems thinking.

So now the question is: Are we done with systems thinking by inventing agile? Not really. Systems thinking discipline can take us much further than what we are today due to many reasons.

First reason is that today many organizations applies agile methods simply as a process and does not understand what agile thinking brings to the table. In this case the discipline of systems thinking can bring them back to some light.

Second reason is that use of systems archetypes can make the organizations to better understand how software development system works and to find the optimal way to operate. Remember every organization is different.

There are many other concepts inside systems thinking discipline such as point of high leverage, reinforcing/balancing feedback, etc. which can help an organization to find the true agile organization or take it to the next level.

Personal mastery

Personal mastery is the process of life long learning to achieve results we truly desire in our life. It is about being master of the what we do. The key to personal mastery is to find the a concept called “Creative tension” which will drive us forward. A further reading on personal mastery: https://www.solonline.org/?page=PersonalMastery

Agile software teams are self managed and consisted of motivated individuals who seeks excellence in whatever they do. Ceremonies such as retrospective look in to what learning which team take forward. Targets such as sprints goals clarifies teams of what they need to achieve. To take out few lines from Agile manifesto principles;

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

“Continuous attention to technical excellence and good design enhances agility”

The discipline of personal mastery provides a framework to team members to improve their skills which requires in Agile software development.

Shared vision

Shared vision is a vision which the whole organization is committed. Shared vision touches heart of the organization and everybody in the organization shares the same vision.

The vision that is shared is by whole organization aligns it towards the excellence. When you look at the agile manifesto, aligning to business vision is the core focus of agile software development. Again to take few lines from agile manifesto

“Responding to change over following a plan”

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Software development teams need to share the vision in order to see the value of welcoming changes even in late in development. When teams share the same vision as business, the highest priority would be to satisfy customer demands would happen automatically.

So the discipline of shared vision provides a framework to help software engineering teams to create, commit & share the organizational shared vision in the true agile organization.

Mental model

Software development is all about making abstractions about real world. Take an example of an order processing software. Order processing happens physically in a factory and software development teams needs to model it successfully to create a valuable piece of software. Object Oriented Programming concepts helped a great deal for software engineering to come to the place where we are today.

In definition Mental models are the abstractions which we make about real life situations. Mental models exists in minds of people and they exists below the level of conscious so people doesn’t realize the existence of mental model. Human forms mental models for everything. For example we build an abstract model in our mind regarding an upcoming version of Windows or year end Agile conference. We form these models based on limited information we tend to hear or find from somebody or somewhere. There is no guarantee that our mental are right and mental models are never accurate. What is important to be aware of mental models and test them.

Extending above example of order processing, let’s look how the mental models works. When the teams looks for requirements, they talk to people who does the order processing. Order processing people describe the process using abstractions. I.e. they describe their mental model of order processing. Then software developers creates another mental model inside their mind.

What agile movement did was to align with the formation of mental models and make them visible as much as possible. For example we use user stories over lengthy documentations so we don’t fix a wrong mental models. (Note: According Mike Cohn the abstraction of user stories provoke the discussion – which is a very good way to test the mental models)

We use personas to model the real users and we use “As a … I want to … So that …” format to model the real user scenarios & importantly understand the story behind the story. Agile architecture is about modeling the software based on what we know and keep opportunity to improve it as we go rather than fixing a wrong mental model. Concepts like sprint planning, sprint reviews, fast feedback, etc. provides opportunities to explore the mental models further. In waterfall we fix the model and it will be very hard to change.

Although agile movement touches the concept of mental models but the discipline of mental models offer far fetched benefits than what we use today. In my view we can use the discipline of mental model to create a new way of working to review & test the mental models which we form over user needs or requirements.

Team learning

Team learning is about learning as a team to create the results. Set of individual heroes does not always produce results unless they make a good team. The important fact to create a good team is that “team is able to learn as a team not only as individuals”.

Agile software development is based on teams not on individuals. We measure team velocity not individual velocity. We perform team retrospectives not individual performance reviews.

Agile manifesto specifies the need of the team but does not specify how to learn as a team (rightly so). There are many books written & many literature about how to create high-performing teams. But the discipline of team learning provides a different perspective based on systems thinking to practice how to work best as a team.

Conclusion

Agile organization is the one we all are dreaming to work for. Learning organization is what it helps to create the true agile organization.

As noted earlier, agile movement provides guidelines regarding what to achieve & learning organization disciplines provides how to do that.

And the true agile organization is just one benefit of the learning organization.

Further reading

http://newtechusa.net/agile/agile-gateway-drug-to-the-learning-organization

http://www.amazon.com/The-Fifth-Discipline-Practice-Organization/dp/0553456342

Eisenhower Box

I was reading this post Eisenhower box from James Clear. (James Clear is one of my favorite bloggers and he posts wonderful posts every Tuesday & Friday)

Eisenhower was the 34th president of USA and he has used a simple technique to prioritize the work. Many of us struggle to prioritize work and the method used by Eisenhower (called Eisenhower box or Eisenhower matrix) would help us a great deal. It is so simple and just knowing it would help us a great deal.

Urgent vs important

This is the corner stone for Eisenhower’s method. According this classification, urgent things are not always important.

• Urgent: These are the work which we need to act immediately. Examples are attending to a frustrated a customer, helping a colleague who is struggling on a piece of work, answering a phone call from unknown number, etc.
• Important: These are the things which contribute to long term vision, objectives or achievements. For example a retrospective meeting is an important piece of work.

We normally don’t recognize or differentiate the urgency vs importance while working. The key to productivity lies on differentiating the above two aspects and we should treat & prioritize work based on them.

What Eisenhower box tells us is to categorize our work based on the above two factors. So it creates a 2X2 matrix. There is a guideline given on how to treat each box.

 

The above diagram is self explanatory and I am sure this can make a huge difference in our way of working and productivity.

Reference : http://jamesclear.com/eisenhower-box

Photo credit: http://content.artofmanliness.com/uploads/2012/05/4.jpg

Managing queue length

Optimizing the software engineering is no easy task. The intangibility of software assets in combination that most of the engineering happens at the human brain makes it difficult to see the whole picture. Optimization requires visibility. This is where the lean manufacturing provides a good foundation to optimize and improve the software engineering as a whole. The pioneers like Mary Poppendieck & many others have already paved the way.

Taking a leaf out of the lean engineering book, one of the important concepts that comes along with SAFe is “Managing the queue length”. The longer the queue, higher the waiting. In lean manufacturing, waiting is  one of the seven wastes. Therefore managing queue length is important.

What is a queue in software development?

At the first glance, we don’t see any queues in software. But if you make a deeper look in to the definition of the queue, you will see many long queues. According to merriam-webster queue is a “line of people who are waiting for something”.

This can be easily mapped to “List of features which are waiting to be developed”. Going further, product backlog is the list which contains the features (user stories). Does this means the product backlog is a queue?

Is the product backlog a queue?

The product backlog interestingly is not a queue. The justification lies on the fact that queues cannot be easily re-arranged and typically works on FIFO basis. If you try to change the queue at the bus or train station, you will not have happy results.

In this meaning, you can change the order (prioritization) of the backlog so it is not a queue.

Waterfall is primarily about long & costly queues

Everything is planned and scheduled at the beginning in a waterfall project. This is essentially a long queue & it defines who will work on what even at the last week. The problem with the queues are multi-fold. It creates long waiting time for new features. The most dangerous fact is changing the queue (schedule in this case) is very costly.

For example if there going to be a change to the requirement, the whole schedule needs to be adjusted. If there are external dependencies such as delivering a component to another team, etc. then it requires lot of effort to change the queue (schedule).

This is the main reason why changes are primarily considered bad in waterfall projects, no matter what benefits they brings to the business. There are lengthy & costly procedures to pass a change in to the development.

Managing queue length

Any experienced Agile practitioner would tell you that they only plan next two iterations. This is essentially keeping the queue length short. Only the current sprint is committed (SAFe even reduces this commitment by introducing a concept called stretch goals) and it is only the queue we have in agile software development in a way.

All the other stories in the backlog are not planned & kept untouched. This comes from the fourth value of the agile manifesto “Responding to change over following a plan” as well as from the second principle of the manifesto “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.“

Why we should have shorter queues?

Benefits of the shorter queues are many.

1. The main benefit is that it facilitate the agility by facilitating changes even late in to development.Also changing is less costly.
2. Secondly it makes the waiting time predictable. If there is an urgent change to be introduced, everybody knows it is maximum of one iteration which they have wait. 
3. Ultimately it supports the business by allowing early realization of business value by reducing the waiting time

Summary

In software development, queues are the stories or features scheduled to be taken in to development.

In conclusion, the queues are bad due to cost of change is significant but change is essential. Agile software development by design limits the queue length and therefore supporting businesses to realize benefits quickly.

The takeaway is to limit the queue size by only planning current sprint and next sprint.

Photo: http://blog.hqc.sk.ca/wp-content/uploads/2012/12/Queue-2012-12-11.jpg

Everything looks like a failure in the middle …

We take decisions to improve ourselves from where we are now. This is common to any significant decision we make in our life. It can be that when we start a new job, new project or even when we migrated to a new country, we expect things to be better than it used to be.

At the start everything is fine and things are happening according to the script.

The new job offers a lot of learning and able to catch up on the technologies/opportunities we missed previously. The new country offers a lot better infrastructure, services, facilities, opportunities, etc. Everything is perfect and positive energy is overflowing. We are thrilled about the decisions we made.

After this initial period, not everything goes well. Things are not folding to the way it should be.

Now we feel that new job does not provide enough challenges or it is not going as per way it was described initially. The new country does not provide the value system which we used to be and we see negative aspects of the new culture. This is the stage where the reality takes over and the negativity slowly emerge. Then we ask ourselves  “Why an earth I took that decision?” We get frustrated on the situation very often and sometime curse ourselves for the decisions we took. We wonder whether there is a second chance where we can correct ourselves. In some situations we goes to an extent to label ourselves as a “failure” or a “looser”.

There is one thing we miss in this situation/context. This is not a situation which we need to get frustrated. This is not a situation where we should label ourselves as a “failure”. This is not a situation which is specific to us. This is a situation which happens to every individual, every organization and it happens every-time and everywhere.

There are many scientific and social research on this perticular subject. There is one such law called Kanter’s Law. It was developed by Rosabeth Moss Kanter, a Harvard Professor. In this law, she argues that we feel “Everything looks like a failure in the middle“. She further goes to explain how one should overcome this middle period. The advice she gives is that “Recognize the struggle of middles, give it some time, and a successful end could be in sight.“

Further details can be found out from her post in HBR https://hbr.org/2009/08/change-is-hardest-in-the-middl/

Another relevant piece of work is called “The Satir Change Model” developed by Virginia Satir, an American author and a family therapist. It is a five stage model that describe how the change happens from one stable position to another over the period of time. You can see that it is not a straight line and there are many ups and downs in the middle. And most notable thing is that the performance in the middle period is far worst than where it started or before the change.

 

 

 

 

 

 

 

Illustration by Jurgen Appelo

The lesson to lean here is that as humans we feel that things will “progressively improve” over the period of time. What we don’t realize is that it does not happen in reality and there is struggle in the middle. World is not linear by any means for things to happen in straight. We need to have patience and push through this middle period.

 

Further reading

http://dhemery.com/articles/managing_yourself_through_change/

http://stevenmsmith.com/ar-satir-change-model/

https://hbr.org/2009/08/change-is-hardest-in-the-middl/

Iterative thinking

THE “WATERFALL” VS “AGILE” BATTLE SEEMS TO BE OVER BY NOW AND AGILE HAS EMERGED AS THE WINNER.  Still the current software development landscape is far from the order. It is filled with many tools, processes, frameworks, methods, methodologies, best practices, procedures (Be my guest …)

This drives many software development teams in to confusion. Outcome of this confusion is that teams have been following processes, methods, etc. just as a recipe. It can be scrum, XP, Lean Start up or even SAFe but you will see many teams use them without understanding the underlying thinking. Probably this is one reason why the (almost) movement “Be agile” had to be born.

It is obvious that teams should not use “Agile recipes“. There is no better reason than the first value of Agile manifesto to show why any team should not use a recipe . The first value states ” INDIVIDUALS & INTERACTIONS over processes and tools”. What has most value is the team itself and the interactions around it, not the use to tools. Teams should understand the basic underlying thinking of these Agile methods in order to be successful.

So the first question is what is the underlying thinking and the second question is whether is there any similarity of this underlying thinking? There is very simple answer to both the questions. All these Agile methods are based on a simple concept of  “Iterative thinking” (at least what it should be). Applying any Agile method just as a tool will not guarantee the success of the project but if one can find the success if he/she understands and applies iterative thinking. In my view, there is no need to use ANY tool or method if one can master and use iterative thinking in a project.

So the big question is what is “Iterative thinking”?

Iterative delivery

 

Iterative thinking is connected to all the areas of software development. Iterative planning, Iterative design, Iterative development, etc. are examples. Iterative thinking can be simplified in to “it is all about slicing the customer need and deliver the solution in a progressive piece meal manner“. One important factor here is that each delivery should ensure that it is build on top of previous delivery and the future deliveries can be build on top of it.

The outcome of the “Iterative thinking” is the “Iterative delivery” and it is an extremely important concept when it comes to complex domains, scopes, etc for the success. When it comes simple software problems, the iterative thinking becomes less visible and just using a recipe can lead to success.

The “Iterative thinking” can be illustrated in an example. Let’s take typical user management feature:

• The first iterative delivery can be a simple screen where users can be added to the system and the added users are listed in a crud list. There are no validations for the user creation form. Not much thought given for the design of the user management feature. The main objective is to get the initial thinking in sync between the development team and the problem owners. This delivery can be called as “User management Spike”.
• The next delivery can be “Basic user management” where more features are beefed up on top the the user management spike. It can be that user creation form has more fields and validations are added, passwords are encrypted, etc. Also the basic design of the the user management has emerged.
• This can be extended to further iterations till the problem owner is satisfied with the given solution.

(This should not be confused with incremental delivery. See this http://goo.gl/MSWRMI)

 

When it comes to complex software problems (such as automated vehicle guidance systems, etc.) there will be many more iterations than a simple user management feature.

• The first iterations can be that nobody touches the code and it is all about presenting (by PPT) team’s understanding on the requirements.
• The next iterations can be further strengthen on design aspects of the system (if team feels a certain up-front design is required).
• These iterations can be further worked on through providing basic integration tests.
• This can continue from the first delivery to final user acceptance.

The magic behind the “Iterative thinking/delivery is rapid & constructive feedback. When a team follows the iterative delivery, the feedback would be specific (such as saying “I don’t need the “middle name” field here, add a new field called “Date of birth”, move the “address” to the bottom, show the last login date/time, etc.) This specific feedback would speed up the team thus resulting rapid value delivery which fits to the purpose.

So in conclusion what can be noted is that the important fact in Agile software development is not to use the tools, processes, frameworks, methods, methodologies, best practices, procedures, etc. as recipes but to understand the concept of Iterative thinking. The simple use of Iterative thinking can lead the successful project delivery even ignoring all the norms and prescribed methodologies such as Scrum.

References:

http://www.mountaingoatsoftware.com/blog/the-one-true-way-to-be-agile

http://en.wikipedia.org/wiki/Iterative_design

Today’s problem and Tomorrow’s problem

Photo credit: http://blog.samanage.com/wp-content/uploads/2013/06/yesterday-today-tomorrow.jpg

I am a great follower of Jim Highsmith and I am still fascinated by his concept “Today’s quality and tomorrow’s quality”. Reference http://jimhighsmith.com/beyond-scope-schedule-and-cost-the-agile-triangle/

I read this long time ago and had a post regarding this as well. But what I realized recently is that the concept of today’s … and tomorrow’s … is more universal than it seems from the outside. It is applicable for many things beyond just quality in the software engineering.

One contrary application of this concept can be found in problem solving.There is a general struggle when it comes to how one approach problem. Going with Jim Highsmith’s concept, there are today’s problems and tomorrow’s problems. We waste lot of our resources (let it be money, time, etc.) finding solutions for tomorrow’s problem.

For example if you are planing a software system to be used by 5 million users (like Trello) without even writing a single piece of line, then it is a waste. In a realistic example, many software designers are being pushed on concepts of “re-usability”, etc. before even a single piece of line is written. [I think the term “Use before Reuse” was coined due to this :)] Finding solutions for those are simple waste of resources.

We struggle in classifying a certain problem to be today’s problems or tomorrow’s problems. As humans we always like to think big and therefore pretty much liking to find solutions to tomorrow’s problems. So it is not easy to identify and categorize whether it is today or tomorrow in the outset.  As I mentioned people waste lot of their resources on solutions for tomorrow’s problem. Let’s see how.

The resources are wasted due to the timing of the solution. In simple terms, if the problem is today, then solution would be for tomorrow. If you implement a solution for a today’s problem, it will give results tomorrow, not today. You have the pain of the problem today anyway no matter what the solution is. If you are sick, then the medicine will make you better tomorrow, not today. If you have a “quality” problem in your piece of software, whatever solution to that would result in improving quality tomorrow, not today.

If the problem belongs to tomorrow’s then where the solution belongs to? It simply belongs to waste basket.

 

Note: Jim Highsmith’s concept of today’s quality and tomorrow’s quality is not about finding solutions for tomorrow’s problem. It is about keep an eye about tomorrow’s problem, which is always a good thing. Avoiding tomorrow’s problems and finding solutions for tomorrow’s problems are two different things.

For example if you exercise thinking that you will become obesity in 10 years time, that is good. All lies in analyzing the problem not finding the solution like in Lateral thinking

Agile

Ken Schwaber's Blog: Telling It Like It Is

I am returning from the Agile Alliance conference. I thought I would share the answer to several questions that I was asked in my session:

1. What is “Agile”
Any software activity that conforms or attempts to conform to the values and principles of the Agile Manifesto for Software Development.

2. If you could add another value to the Agile Manifesto, could you state it?

We value practices, tools, consulting, coaching, and software organizational work that continuously improve their adherence to the Agile Manifesto
OVER
Tools, products, methodologies, processes, practices that only use the word Agile to market themselves to make money and whose correlation to the Agile Manifesto is coincidental.

View original post