Brittany plays the guitar and sings
Trying to get a Podcast onto my Blog
This should be easier to do.
Archive for the ‘Uncategorized’ Category
Decomposing Agile
In my post yesterday I talked about the Big Agile Capability Model. I received comments ranging from “We don’t need processes in Agile” to “CMMI already supports Agile”. I actually agree with both of those statements. We don’t need a highly detailed task list that doesn’t allow for flexibility or creativity in the creative steps of building software. In fact, we need an approach that allows for a lot of interaction. But we do need to work with intention – we don’t need to be reinventing every interaction every time. And while CMMI does support Agile, it doesn’t look or sound like anything Agile people talk about. It hasn’t historically resulted in Agile behaviors developing within development teams. I believe that the very approach of implementing processes with complex names so that are auditable results in behavior that is contrary to the Agile approach.
A Capability, as we define it, is ““an ability or capacity the organization relies on for a specific purpose or outcome”. No where do we say you need a highly documented and rigid process that must be followed and all forms filled out in triplicate. We aren’t describing a step-by-step process. Process is a “how” discussion within capabilities – capabilities are about outcome and purpose. They are highly interconnected. If you have clarity on the outcomes and purposes you desire from a capability, you begin to have a reasonable shot at coming up with a way to do it that works in your organizational context.
So, capabilities aren’t bad. They exist whether you do them intentionally or not. Our goal is to come up with a capability model (or lenses) to serve two purposes. First, we want to establish clarity what makes Small Team Agile work. This is important because as we scale, we still need to focus on delivering value to the customer through our small teams. Second, we want to build a framework that is understood by the Agile community to talk about these capabilities through all the orders of scale.
To walk you through our process, we are basing our model on a decomposition Scrum and XP. We look at the common roles of Product Owner, Scrum Master, and Team and identify the capabilities that typically are the responsibility of each role. The names and descriptions of the capabilities will be massaged some as we receive feedback and fine-tune our approach. But essentially, these are the capabilities that exist on most successful Agile teams today.
| Product Owner | |
| Set Vision | Define a high level vision of the goal of the product and how it will be met. |
| Define Product Roadmap | Articulate the big blocks of Features and Customer Value that will be delivered to achieve the product vision. |
| Define Requirements | Generate a description of the features and stories that will be fulfilled to execute on the product roadmap. |
| Maintain Backlog | Order the features and stories. Elaborate on enough stories to meet the near term needs of the team. |
| Achieve Customer Acceptance | Get the customer to look at the product and provide feedback. Sometimes this feedback is acceptance and sometimes it is more input for the backlog. |
| Engage Stakeholders | Keep everyone involved in the product fulfilling their obligation to the team and informed about expectations and status. |
| Planning | Decide on a delivery date. Keep track of the burn down charts. Provide information to management for decisions. |
| Coordinate External Resources | Get anything the team needs from outside. |
| Financial Management | Produce any financial reporting that is needed to responsibly manage the product. |
| Manage Suppliers | Make sure any third party suppliers are clear on their goals and are providing what is needed by the team. |
| Scrum Master | |
| Ensure Process Adherence | Facilitate agreement on how work will be performed. Then make sure the team does what it agreed. |
| Identify & Remove Impediments | Identify any impediments to the team’s productivity and remove them. |
| Ensure Internal Communication | Make sure the team is having the right conversations to ensure productivity |
| Maintain Work Environment | Keep the team free from external interruptions. Protect the teams from disruptions in work. Address Conflicts. Make sure the team doesn’t work excessive overtime. |
| Develop Team | Make sure the right people are on the team. Promote cross training and skill development among team members. |
| Team | |
| Coordinate Work | Work together to coordinate who will do what work. Swarm on work to ensure everything is completed according to the teams agreed up cadence. |
| Maintain Architecture | Agree on how the product will be structured. |
| Understand Requirements | This is where the requirements/stories are explained to the team. The Team has responsibility to understand what the customer is asking for. |
| Maintain Code Quality | Through patterns , code standards, continuous integration, effective branching, and configuration management. |
| Design and Engineer Solution | Actually deciding how to write the code and writing the code. This includes unit tests/automated testing. |
| Production and Support | Moving the code into production. |
| Everybody | |
| Learn from Outside Sources | Understand how other people are solving the problems you face. Learn from multiple bodies of knowledge. Bring in knowledge from the outside to apply to your team. |
| Commit to Agility | I don’t know if this is a capability. There is some action that results in intentionally deciding to be agile. As the multiple decisions are made in the course of performing the effort, your team might need to remember to recommit to Agile. |
| Manage Risks | Agile in and of itself is an approach to risk management. Through small bets, constant feedback, early learning, and shared insight the team stays focused on threats to the delivery of value. There are numerous other risks and it is important to everyone to scan the environment and help manage the risks. |
| Train for Job | This is similar to Learn from Outside Sources but it involves developing personal mastery of different skills required by the team. |
These capabilities should look a lot more familiar to an Agile team than the list of RUP or CMMI practices. The fact that you can map these to CMMI doesn’t make them familiar or encourage agile behavior. And we haven’t documented detailed processes in any of this. It is to understand the purpose and outcomes you are need in each capability and then intentionally work toward those purposes and outcomes. It is also important to understand how any improvement in a capability is going to improve your ability to optimize value delivery.
