This posting, the latest in our series focused on a disciplined agile approach to continuous improvement, overviews the activities associated with it. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog posting we present the goal diagram for the Continuous Improvement process blade and overview its process factors.
The following process goal diagram overviews the potential activities associated with disciplined agile continuous improvement. These activities are performed by, or at least supported by, a process improvement team (sometimes referred to as a Software Engineering Process Group, or SEPG).
The process factors that you need to consider for continuous improvement are:
Future blog postings in this series will explore the workflow between continuous improvement and other process blades as well as the internal workflow of a process improvement team.
Retrospectives are a great way for teams to explore potential improvements to the way that they work. A team will get together, discuss what is working well for them, what is not working so well, and hopefully identify ways that they could improve. It’s this last activity that can be challenging. You may know that your team is facing a problem but you might not understand your options. For example, perhaps your team is struggling with the way that it is being funded. The current funding mechanism is to estimate the cost up front and then allocate these funds to your team. This motivates your team to be wary of changing requirements due to the fear of going over budget, something that decreases your ability to produce a solution that meets the true needs of your stakeholders. You have suggested to management several times that a time and materials (T&M) approach would be more appropriate, but you have gotten nowhere with that conversation.
This is where DAD’s process goal-driven approach can help out. In this case the goal Secure Funding provides some insight. The process goal diagram, see below, along with the supporting descriptions of each technique, their advantages and disadvantages, and advice for when the technique is applicable can help your team to understand their options and hopefully argue for a better funding strategy. Although a T&M approach might not be palatable to your financial team right now, perhaps they would be willing to consider a stage gate approach to funding. Or, perhaps they would be open to a T&M approach but they just don’t understand the tradeoffs between T&M and fixed cost. With DAD’s goal-driven approach the team can arm itself with the arguments that it needs to have a knowledgeable conversation with the actual decision makers.
Of course this is just one example. The DA toolkit addresses a range of goals pertinent to successful agile solution delivery, all of which can provide team’s insight into potential process improvement options. Knowing your options is an easy way to up your game during retrospectives.
An important philosophy within both the agile and lean communities is that a team should own its process. In fact, one of the principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The idea is that teams should be empowered to tailor their approach, including both their team structure and the process that they follow, to meet the unique needs of the situation that they find themselves in. Teams that own their process will tailor it over time as they learn how to work together, adopting new techniques and tweaking existing ones to increase their effectiveness.
As with most philosophies this one is easy to proselytize but not so easy to actually adopt. When it comes to process improvement, teams will exhibit a range of behavior in practice. Some teams see process as a problem and actively seek to ignore process-related issues. Some teams are ambivalent towards process improvement and generally stick with what they’ve been told to do. And some teams see process improvement as an opportunity to become more effective both as a team and as individuals. This range of behaviors isn’t surprising from a psychology point of view although it can be a bit disappointing from an agile or lean point of view. It has led me to think that perhaps some teams choose to “own” their process but many more still seem to prefer to simple rent it.
The behaviors of people who rent something are generally different than those who own something. Take flats for example. When you rent a flat (called an apartment in North America) you might do a bit of cosmetic work, such as painting and hanging curtains, to make it suitable for your needs. But people rarely put much more effort than that into tailoring their rental flat because they don’t want to invest money in something that isn’t theirs, even though they may live in the flat for several years. It isn’t perfect but it’s good enough. When you own a flat (called a condo in North America) you are much more likely to tailor it to meet your needs. Painting and window dressings are a good start, but you may also choose to renovate the kitchen and bathroom, update the flooring, and even reconfigure the layout by knocking down or moving some walls. One of the reasons why you choose to own a flat is so that you can modify it to meet your specific needs and taste.
You can observe similar behaviors when it comes to software process. Teams that are merely “process renters” will invest a bit of time to adopt a process, perhaps taking a two-day course where they’re taught a few basic concepts. They may make a few initial tailorings of the process, adopt some new role names, and even rework their workspace to better fit the situation that they face. From then on they do little to change the way that they work together. They rarely hold process improvement sessions such as retrospectives, and if they do they typically adopt changes that require minimal effort. Harder improvements, particularly those requiring new skills that require time and effort to learn, are put off to some point in the distant future which never seems to come. Such behavior may be a sign that this “team” is not even be a team at all, but instead a group of individuals who are marginally working together on the same solution. They adopt the trappings of the method, perhaps they spout new terminology and hold the right meetings, but few meaningful changes are actually made.
Process owners behave much differently. Teams that own their process will regularly reflect on how well they’re working and actively seek to get better. They experiment with new techniques and some teams will even measure how successful they are implementing the change. Teams that are process owners will often get coaching to help them improve, both at the individual and at the team level. Process owners strive to understand their process options, even the ones that are not perfectly agile or lean, and choose the ones that are best for the situation they find themselves in.
The Disciplined Agile (DA) toolkit is geared for teams that want to own their process. The DA toolkit is process goal-driven, not prescriptive, making your process choices explicit and more importantly providing guidance for selecting the options that make the most sense for your team. This guidance helps your team to get going in the right direction and provides options when you realize that you need to improve. DAD also supports multiple lifecycles because we realize that teams find themselves in a range of situations – sometimes a Scrum-based lifecycle makes sense, sometimes a lean lifecycle is a better fit, sometimes a continuous delivery approach is best, and sometimes you find yourself in a situation where an exploratory (or “Lean Startup”) lifecycle is the way to go.
You have choices, and DAD helps guide you to making the choices that are right for you in your given context. By providing process guidance DAD enables your team to more easily own its own process and thereby increase the benefit of following agile or lean approaches.