A brief history about agile transformation

-
By re-reading a post from a friend of the honey-badger tribe, I realized how much in common it has with a known situation experienced in a recent past.

Imagine you join a team in the following situation:
  • Unclear processes and workflow
  • Lack of knowledge about the product
  • Team executing decisions taken by others
  • Vague software development practices
Also, within this context, imagining you receiving a great market opportunity which requires deliver something with a fixed deadline. Looks like a case to continue doing what's done in the past to avoid taking risk of failure, but off course leaving the same picture as above regarding team processes. There is always the chance to be counterintuitive and use this greenfield project to boost the team processes to another level. The good thing is to have an organization aware of this issues and the willingness to support any change that improves the way they work. So, having this context, the willing to improve it and a deadline to fulfill, how would you do it?

Well, there are no silver bullets for the transition of organizations to become agile organizations. But there some things they had that helps to start trying small steps towards that end:
  • Acknowledge the problem
  • The willing to solve it
  • The opportunity to start solving it
Having all these ingredients in mind you define a new way of working based on Respect, create space for continuously improve Communication, Collaboration and Learning. This new way of working has open doors to constants Feedback, the process will be constantly evolving and adjusting to our needs and conform, applying the Inspect and Adapt cycle ( see the twelfth principle of the Agile Software Development). Basically, you invert the pyramid by rejecting receive only solutions from the stakeholders and instead receive more customer oriented needs which allow the team to respond back with solutions created by themselves.

Is important to emphasize that you don’t call this new way of working Scrum or Kanban nor XP, you just get some techniques of those frameworks and apply them into your context; and this is one of the key things we need to understand about agility: We aren’t more agile just because we do Scrum or eXtreme Programming, we should first understand the context in which we are playing and create our own process improve Adaptability, Risk Management and Innovation within the organization. To achieve it I do agree on choosing the best practices and techniques from others methodologies or cultures like Scrum, Kanban, XP or DevOps just to mention some of them or create your own artifacts that simply leads the team or organization to that end.

Let’s review some of the things that the team has tried:
  • Begin with the end in mind: Having today a clear image of the end of the work is the key reference for the team to measure accuracy on every single step or iteration they do. In reference to the book: The 7 Habits of Highly Effective People
  • Retrospectives: Part of the previously mentioned feedback loop. They do it periodically, rotate the facilitator and set concrete actions to improve.
  • Planning meetings: The conversation should be the focus in having a common understanding of the problem that need be solved using customer/business language. Then the teams should decide how to solve it.
  • Working towards having Continuous Integration, which not only having a build server that runs tests for every commit but also has the team mindset that code should be integrated altogether the sooner the better avoiding long-lived branches and unwanted conflicts, errors and miscommunication.
  • Working towards having Continuous Delivery
  • User Stories: Reduce the risk of failure by having granulated and acknowledging the added value.
  • Reduce Work In Progress (WIP): To Increase focus, collaboration and detect bottlenecks.
  • Demos: Another part of the feedback loop where several roles should meet and talk about the increments of the product. Sharing knowledge and checking if we are all moving in the right direction.
  • Pair Programming: With the objective of sharing knowledge, reduce knowledge silos, increase team cohesion and improve code quality.  
  • Automated Testing: Still not Test Driven Development, maybe in the future.
At the end of the deadline, the results talk by themselves by having a team behaving close to a self-organized and autonomous team, having collective ownership over the code, having better understanding of the product and the impact they have over it, understanding the process they follow to add value to the organization and how/when this process can be improved. All this can be achieved because the organization simply give them trust and freedom to do, fail, success and act in consequences.

At the end of the deadline, the team should have been doing the right thing and after they should focus on doing things right. Meaning that you should first focus on the user needs, lean processes, feedback loop, ... ( the right thing ) and then look for technical excellence, reduce lead times, reduce feedback loops among others by polishing DevOps culture, XP practices, etc. Always keeping the continuous inspect and adapt cycle.

Related resources:

Comments

Post a Comment

Popular posts from this blog

Baby steps

-
I have two kids and nowadays they cannot stop running, jumping, and spreading energy all around. A few years ago the running and jumping skills weren't part of their toolbox, they crawled and step by step they learned to walk. Do you have kids? Do you have nephews or kids in your neighborhood? Have you stopped for a second and think thought carefully about how what the process of learning to walk is? Let’s imagine for a second your baby is crawling. Don’t be scared if you are not a parent, just bear with me and imagine you are sitting on your couch in the living room, your baby stops crawling just in front of you. She looks at you, sits down and from there tries to stand up and poooom, she is pushed back by her own body and gets to sit down again. She tries without success multiple times but never gives up until fatigue overcomes her. The next day she doesn’t feel defeated at all, she is fully energized to try again to stand up on her feet. After 5 minutes you see yourself holding
Read more