Part Two: Five Equals One?
We left off with the cross-functional leadership team being asked by senior management what our organizational Agile objectives were? Going into this exercise I thought this was going to be easy. This should already have been figured out right? Well, it seems that my asking questions resulted in the job of pulling the leadership team together to come up with our objectives.
My first step was to work with the engineering leadership that had been running the “roll-out.” They had also been reporting on the Agile transformation status. I began by collaborating with them in the construction of these objectives. I was careful not to create the objectives for them. I was joining the team in the middle of all of this, so I didn’t want to seem challenging or dominating. The initial drafts that came back seemed like all the objectives were being pulled from Google searches and existing Agile websites. Who doesn’t want to eliminate waste – right?
The team and I tried to create objectives that were specific to what we needed to do and to put it into a language that Senior Management would understand. In other words, what we needed Agile to solve for us. Below is a summary version of that final draft. I’ve kept the integrity of the actual document, but removed all company and person references to protect the innocent.
Our 5 Agile Transformation Objectives
Q: Why are we transitioning to Agile?
A: <Company name> is transitioning to an Agile product development approach in order to do the following:
- Build products that are closely aligned to rapidly changing customer and market needs
- While improving quality and shortening time to market, in order to,
- Realize gains in both revenue and cost efficiency
We have overwhelming evidence that we need:
- Great visibility into project progress (transparency)
- Greater predictability with roadmap execution
- Leading to greater confidence from our customers
We need to operate as a “team” and leverage all the benefits from “team work”!
Agile uses interdisciplinary (cross-functional) teams in iterative cycles. It’s based on strong cross-functional communication where the work is broken up into smaller pieces with the overall goal of getting something “done” sooner – allowing more upfront feedback during the entire process, rather than later, when it’s too late and very expensive to change.
Where we can, we need to move from project thinking to product lineage thinking.
Our specific objectives are the following (this is what goes into our performance objectives!):
- Obtain early and ongoing customer feedback so we build only what is needed
Why?
- Industry data suggests that typically 40% of functionality built in a product is never used (e.g MS Excel). At <company name>, we currently don’t have any data around this topic. We may be better or worse. Using the Agile methodology will help us get this key metric so we can better assess and improve our approach to feature selection.
- Maximum leverage of investment dollars to only invest in what customers really want. The Agile approach allows us to achieve this objective by providing shorter feedback loops and predictable release cadences.
- Agility to adapt to changing customer and market demands. At <company name>, an example of where we see this situation, and why we need to develop this approach as a core competency, is through some of the quality issues we have been able to address in a more predictable way as we balance those issues against release features.
2.0 Improve time-to-market by regular releases of “workable” product components – rather than a big bang[
Why?
- Harvest Return on Investment (ROI) earlier
- Enforce tighter “partnerships” with customers as our products and solutions evolve
With the number of incremental feature type investments we’re doing, Agile is more aligned with our current portfolio and resource strategy.
3.0 Organically drive out waste
Why?
- Focus on waste reduction to increase efficiency
- Build sustainable systems
Driving out waste means looking specifically at these 7 things:
- Partially Done Work (This is the software equivalent of inventory – it’s work that has cost, but no value. Frequent releases and production ready code through continuous integration helps keep this to a minimum)
- We have been experiencing this over the years quite a bit as we start projects and move off of them or move in and out of variable resource models
- Relearning (managed change and root cause analysis exercises help to reduce this) – Agile gives us dedicated teams with dedicated investment strategies
- Task switching (Dedicated teams and reduction of WIP (work in progress))
- Hand-offs (one piece flow – understanding workflow solutions in the development process itself – mistake proofing)
- This is pretty important, but also somewhat nuanced – at least at first. While more communication is important (you can never eliminate hand-offs), but hand-offs have overhead because of information exchange and the increased chance of dropping key data. For example, think of calling tech support and being handed off two, three, or four times – you never know what was missed, and you often have to tell your story over and over again. Now think of that example, but instead of telling your story over and over again, someone else is telling it. The information and original content can degrade quickly, and you can end up with a story (or product or service) that is a pale reflection of the original
- Delays (developing systems and infrastructures to support cadenced releases) – ok, but how do we incorporate App ops / Tech ops / Ops into this. Right now, this is a lot of where we experience project delays.
- This may be where we increase the scope of the PMO as an orchestration layer between these points to create a seamless interface. Flow will need to trump process!
- Extra Features (covered in customer feedback, but this is also about creating a ”product lineage” culture and team mentality. This means that product management does not have to worry about not getting to the next release – as long as there is market value)
- Defects (covered in building quality in)
4.0 Improved employee engagement increasing employees vested interest in their products
Why?
- Self-organized teams
- Empowered product management more closely aligned with engineering, to bring customer feedback to the requirements process. 1) feels like our organizational construct is somewhat widening the gap, 2) we need to focus on the empowered product manager or empowered teams concept because we’re reporting upward to executive teams at a much more granular level than in past years trending, at least in the short term, toward less empowerment.
Build quality in for better quality products –“Early Defect Detection and Prevention”
Why?
- Products are trusted, leading to happier customers and the strengthening of the brand
- Increased internal operational efficiencies
- Automated test driven development – automating testing rather than manual and error prone
- Testing within each iteration/product component drop
The five objectives, listed above, were passed around and presented to Senior Leadership. During the discussion, most of the feedback could be summarized as “yeah this looks good but so-what” and “great – but tell me where we are in the roll-out process? When can I expect to see results?” and “So, generally I’m fine with this, but how do we do this on product/project <name>?”
During that discussion, I began to drive the idea that transforming an organization to Agile development should be done in an Agile manner as well. To think that we’re going to train the entire organization and then say “go do it” was not going to work. Considering all the projects we had going on, there was no way we, as a management team, were going to be able to keep track of, support, and actually manage the roll-out in that fashion. We needed to do the following, if we were going to be successful.
- Agree on our investment strategy for 2013 and identify the top 3-5 we wanted to manage through Agile. I recommended a cross-section of work – some new product development, some incremental feature enhancement, and some maintenance. I wanted to make sure we had enough of a sample size and were exploring all the types of work we were doing.
- For each initiative, I wanted specific outcomes that we wanted to achieve by using Agile. I knew they would be different depending on the work we were doing, so I wanted a deliberate measurable outcome for each.
However, the general theme from the group was that we needed one common objective. After a small discussion we all agreed that it had to be “increase the bottom line.” Call it what you want, if we were going to do this Agile deployment and roll-out, then we better see results. And those results better be financially based if they’re going to carry any weight with senior leadership.
The next steps identified in the meeting were to further describe the engineering transformation that needed to occur from waterfall / iterative (current state) to Agile. I will share a summary view of that presentation and the feedback it received in my next post.
Stay tuned!