Imagine: you are a customer of a big software project that tangled in chaos. Several practices will help you make your project manageable and profitable.
Meet John
Imagine, that you are John, a customer of a large and complex software project. You and your development team have done a lot of work, however, the project tangled in chaos. Your personal investments still should still return as a profit from the users of your team's product.
John's questions and findings will help you to better organize your project.
All names are fictional. Editors may not agree with John's conclusions :).
OK, let's read what John wrote in his diary.
John's preamble for his diary
[John is saying to himself – editorial comment]
Hey, John, you are not old, but you feel exhausted :(. Buddy, it seems, your IT project is going wrong.
OK, then. I will start writing the diary, because I need to understand what is really happening with my project.
How I decided to invest in a software project. Risk worth embracing
Since my childhood, I definitely wanted to become a businessman. I studied hard and got the highest grades at school and university. After the graduation, it took me 10 years to earn my savings of $100K. I thought a lot about how to invest my money best. After a long search and comparing I realised, that information technologies is the domain of rosy future but of big risks as well. Like thorns on rose bushes.
I have learnt that the gloomy statistics of the IT projects results. The majority of software projects are failures!
The CHAOS report on the software project management: dynamics of success, challenge and failure. (C) Standish group [2].
But I realized that the software projects are profitable and they have a great future. There will always be a need for good software. Information technologies are in high demand.[3]
A cactus with both thorns and blossoms is like software project management with both chaos and profit. Pixabay / Foto-Rabe
I started planning an augmented reality project, then a speech recognition project, but a musical social network won the investment eventually. OK. I hired a team of five guys who are really smart and active.
1. Chaos in software requirements. The first project management failure. Iterative process
… In the beginning all went well. We agreed the requirements for the first prototype. The idea was to build a simple iOS app that should have the only functionality – share a song with friends.
While the developers were implementing the prototype, I discovered several very useful aspects that were crucial for the product on the market (integration with two popular social networks). I assumed that the changes would not affect my budget and schedule a lot. However, the developers started complaining that the changes were rather and we need to rework the architecture.
I felt embarrassed, because we had put off the release date 3 times. The developers told me that we changed the requirements too frequently.
I recognized the problem when I joined one of the developers' meetings. After each small change request they started reworking the system architecture. Otherwise, they would have to make quick and dirty solutions. Quick product changes would not allow us to accomplish even the first version. I treat this problem as my first project management failure. Frequently changing requirements are like a ship in a storm.
A software project in chaotic requirements is like a ship in a storm. Robert Salmon – "Ship in Storm".
And I fixed the problem using Agile (particularly – Scrum). Iterativity of the Agile gave a great mechanism both for product changes and developers to have some stable time within a sprint. In Scrum, the product owner can change the requirements before each sprint, the development team has guarantees that the sprint goals will not change during the sprint.
Scrum diagram. How the iterative process harnesses the software project management chaos
Excellent! What if I just cancelled the requirements changes and killed the chaos? It would kill the ability to respond to the market needs. Iterativity prevents feedback dependencies, which leads to the wild chaos [1]. So, let it be constant changes, manageable changes.
That became my first lesson: have possibilities to change requirements for the users needs – use the iterative process of Scrum to manage the chaos of changing requirements.
2. Chaos in workflow. Bureaucracy vs flexibility of project management
I loved scrum, and practiced it a lot. I felt chaos in our workflow.
After it I liked the idea to have an ideal workflow to shorten the time losses as much as possible. My consultant process engineer created a lot of rules and practices for the team to follow: the flow of Jira issues statuses, code-review, unit-tests, integration tests, load tests, configuration management and releases. I started using a more predictable workflow. After the next sprint we delivered almost nothing (!). I tried to keep calm. But we were not productive during the following two sprints.
We spent a lot of time on adjustments of our new process. Until everybody got sick of it :). The more details there are in the process, the more time we need to adapt to new technologies and product ideas, the less time we have to add the value.
The rules began competing with each other. It may cause chaos in the project workflow.
There's my second lesson: let your workflow change, set up only several common rules, that can be changed easily.
It can be a little chaotic, but less time consuming and more flexible and productive then. It was a very expensive lesson…
3. Chaos in the team. Encourage trust and openness
Honestly, Scrum looked well in the Scrum guide only. But it requires the equality of each development team player. In my team I had only one nerd of high agreeableness – Mike. The rest of the team were really proactive and even explosive people. All team members were really smart.
Once they decided to develop a first "killer feature" of my project. Everyone had their own solution and were trying to prove that they were right. A holy war started. The fierce fighting. Chaos in the team.
Solving the conflicts I got a headache and heartache.
The chaos in the team may cause a holy war.
I like democracy, because I believe that it encourages creativity. But democracy, not chaos and not the holy war.
I came to recognition that the people are everything in an IT project.
What if my employees would not be so active and creative? We would fail. But we haven't!
The goal is to make the chaos constructive and collaborative. I like how Scrum solves the problem. It inspires 5 values: commitment, courage, focus, openness and respect. With no bureaucracy or hierarchy with extra management.
Here's a citation from the Scrum Guide:
Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.
Here's my third big lesson: some grade of conflicts is healthy; engage people's energy in a coherent and constructive way.
You manage the chaos
Why do software-intensive projects have such unsuccessful in meeting deadlines, saving, and providing what the customer needs? The answer is the chaos of the playground:
- the market,
- the dynamic technologies,
- the smartest engineers, etc.
Harness the chaos. If your team is boiling, it is alive and electric. Foster it and ripe the harvest.
Chaos in software project management is profitable
Chaos in software project management is OK. Chaos has its hidden energy and force to outrun competitors on the end-market. Moreover, the new areas of the market are profitable because of chaos and the corresponding rules.
Here are John's hard-won lessons:
- use the iterative development process to adjust to changes fast;
- keep rules simple;
- invest in the emotional development of the team.
References
[1] Juhani Kiiras – Project Management in Chaos [2] The Standish Group 2015 Report – CHAOS [3] Jules Ehrhardt – State of the Digital Nation 2016 [4] By Englund, Randall L. – Applying chaos theory in a project based organization. [5] The Scrum Guide™, 2016