the go-to software development approach used in many companies, big or small is the Agile approach. However, it is also the most misused, abused and misinterpreted one on the market today. In this article I would like to point out basic principles to newcomers and approach I focus during a project.
Most of the new adopters of Agile get bogged down on practices like planning, grooming, and lose the focus on why they wanted to move to Agile in the first place. Even though planning, grooming and estimations are important, if you overdo it that's all your team will produce. They miss the whole idea of going Agile, the value it brings, and ultimately miss the delivery. Then, they blame Agile for it.
In this article, I will try to explain this new way of doing things and the whole point of going Agile.
The way I see it, 'Agile' is both a mindset and an approach. To be more specific, it's a mindset-shift in the way how things get done. It holds a common set of values & principles which we should follow.
Autonomous Teams
The Agile way of doing things is a radical change to development teams who are used to cowboy style (go do it style) or waterfall development (extensive planning) practices. The traditional way of doing things involves team members working in silos, to produce what the client needs. Then, there is a Development Manager, Project Manager, and more other managers to make sure that the team delivers what the client needs. Since each member works in silos, nobody knows exactly how the system behaves as a whole, therefore, they rely heavily on documentation, meetings, specs and so on, which consequently means less development or stressed development.
In such a project environment, a small requirement change would cause a domino effect towards all of the documents and work that has already been created or performed by members in each silo. If poorly managed, such changes can happen repeatedly in the project life cycle, leading up to unnecessary re-work, waste, and can be overall unproductive. The Project Manager will have to compromise resources, schedule, quality or budget to be able to finish the project. Sometimes, due to overwork, and stress some development team members can leave in the middle of the project.
The new replacements will be stuck with a product they don't know or will have to read a bible of documents to understand, and rewrite most parts of the system. So, it goes in a vicious cycle. Sounds familiar?
In Agile, things tend to be different. There is a Product Owner whose main responsibilities are representing the client's voice, getting work items ready in the pipeline, according to requirements, and acting as the main point of contact between the stakeholders and the development team or facilitating that interaction closer to the team as possible. Now this doesn't mean team cannot help customer to discover the requirements. Because most of the customers don't know what exactly they want since they are thinking from the process they already have (this is another article by itself). But one thing is important customer should have the final say. Team shouldn't go and build the whole product without customers input.
A good Product Owner will always have the Product Backlog items ready just enough & just in time, aiming to maximize the value that the development team produces.
Then there is an Agile PM, often called a Scrum Master, whose main responsibilities are to align the team on the Agile values, coach them in self organization, protect the team during a sprint from any external or internal threats and distractions, and most importantly to remove any blockers that may prevent the team from achieving the sprint goal. If you have high trust teams, teams that has growth mindset and cross learn fast you may not need scrum masters. So if you could make such teams focus on that. Will pay off in long run.
But who's responsible for managing the team? In Agile, the team manages itself. While the Product Owner decides the "WHAT" and has the last word about what is needed to be done in each iteration, it is up to them to decide the "HOW" and get the job done. This level of autonomy gives them a sense of ownership on the work they do. The team is cross-functional and no longer works in silos and everyone knows what they need to do in order to contribute for the end result.
To achieve a goal, the team starts by focusing on one task. They identify this task by examining the problem and the system as a whole. Techniques like event storming, process modeling, or event modeling can be used, depending on the team's familiarity. This helps the team understand the problem and see the bigger picture. The idea is to discuss the problem hands-on until everyone understands what they're building. Then, they move on to the next task.
So how does they work together? Something highly recommend is patterns of ensemble programming (Pairing, Mobbing). This whole team approach gives the best view at the problem plus no async code reviews that way (more about this in a later post)
It goes without saying that an effective Agile team has a high level of self-organization. Nothing would stop a team member to raise an impediment and do what they could to unblock themselves. This kind of behavior is more encouraged rather than suppressed by the higher management practicing Agile.
Giving this kind of control back to the team, by the top management, is chilling for traditional managers, but it is part of changing the employee mindset. The managers have to trust that the team will do the right thing.
As a manager, you give the team a clear goal and let them achieve it. They might not get it right on their first attempt, but if you keep encouraging them and adjust the team culture accordingly, it will produce autonomous teams that can deliver faster results. The biggest lesson for anyone coming from a traditional development background is to be prepared and to have an open mind to "unlearn", or lose the old baggage, and to learn the new way of doing things. If you are a newcomer, I would recommend sticking to the Agile Manifesto values. These are the core values that will help anyone who is starting out in Agile and whenever you find yourself wandering away, come back to them.
Enabling business capabilities
What is a business capability? There could be numerous fancy and complicated definitions out there to coin this term, but a business capability is what the business does at its core to deliver value to its customers and stakeholders.
Business capabilities are usually defined by the customer or the stakeholder, as I mentioned before team could help the customer to discover these valuable points. Same applies for the team. They can help the Product Owner to discover more valuable capabilities, but in the end, the customer has the final say.
Who is responsible for delivering this? Even though the Product Owner provides the goal for each iteration, in an Agile environment, it is the team's responsibility to achieve the work at hand.
Whenever the Product Owner presents a PBI to the team, or whenever the team begins to produce something, they must be sure that they are enabling that business capability defined. If not then what's the point of developing something in the first place? Like a good Product Owner, the team should always be clear on the business capability that each story delivers.
Strategically managing complexities
Complexities come in many forms. You need to have an appropriate strategy when dealing with these issues and each depends on the problem space you are dealing with. We can sort these strategies into many categories.
Just to name a few:
- Architecture strategy to manage domain complexity
- Test strategy to manage risk complexity
- Deployment strategies
- Reporting and visibility complexity
And the list goes on and on.
In Agile, when dealing with complexity, you should always align your strategy with the business capability you are delivering at that point, in the project timeline. As a rule of thumb, the team should commit to items that deliver the most value just in time and just enough, always experimenting and adapting in the project.
"Product Development is like an investment. You put some money in (mostly time) and hope to get a return. But to succeed, you must first survive, and you only get to survive if you deliver.
- rule: deliver first
- rule: don't invest more than you can afford losing -Vasco Duarte
_Vasco Duarte on LinkedIn https://www.linkedin.com/embed/feed/update/urn:li:share:6525631611462053888?source=post_page-----11cb510de7b5--------------------------------
Imagine running a desert-based shopping chain with shops every 50 km, selling diamonds and water. To maximize customer satisfaction, we advise customers to buy more water at the start and more diamonds towards the end. Without timely and adequate service options, we risk customer dissatisfaction and loss of repeat business.
Similarly, in an agile project, we can provide the client with just enough, bare-minimum items to get him going in the beginning and deliver fine-tuned, expensive parts towards further along the journey and proper architecture should enable the client to do these maneuvers down the lane without paying a hefty price.
This "just enough" and "just in time" strategy leads to smaller, more frequent orders and deliveries.
There are three techniques for managing complexities and enabling delivery:
- By incrementally doing small changes on iterations and continuously integrating to enable business capabilities
- By doing disruptive change that makes a big impact
- By innovation thus eliminating complexity altogether Reducing lead and cycle times.
Agile is built for delivery, so lead times and cycle times matter. Reducing lead times and cycle times is one of the most important things to Agile practice, so let's look at what they mean.
"Lead time is the period between a new task's appearance in your workflow and its final departure from the system." (Source: Kanbanize)
In summary, lead time is the duration from feature request to delivery, visible to clients or stakeholders. Cycle time is the period from when a team picks up a feature to its delivery. The time between the feature request and when the team starts working on it is seen as waste. Teams are encouraged to optimize their workflow to minimize this waste.
Communication with the client through Agile ceremonies like daily stand-ups or sprint demos is crucial as it provides insight into the team's progress during the cycle time. If you need to go faster it might even be helpful to ditch these ceremonial stuff and involve the client. Lack of communication can cause significant issues as the client may be unaware of the development process. Therefore, maintaining open feedback loops between the client and the team is essential.
Agile's focus is to enable business capabilities by reducing lead and cycle times. This requires strategic management of complexities using self-governing teams. When uncertain, adhere to the core Agile values to stay on track. Once proficient, customization can be introduced without losing sight of the primary focus.
Top comments (0)