Wednesday, August 5, 2015
Sunday, July 26, 2015
Friday, July 24, 2015
- Provide Agile Teams with the support, guidance and coaching they need to get the job done
- Improve and accelerate your product delivery by improving your Agile Transformation
- Provide clarity through a well defined feature backlog
- Hold Agile Teams accountable for making and meeting commitments
- Demonstrate measurable progress by facilitating the demonstration of integrated features
- Provide timely information to Portfolio Management for investment decisions
Wednesday, May 22, 2013
Yesterday, I returned to a big company with a pretty complex product portfolio where we had done quite a bit of work including starting up multiple Scrum teams. I recalled our first release planning with this group several months ago. There was a lot of uncertainty and even some anxiety about this “lightweight” approach.
Wednesday, September 19, 2012
When working with organizations in Agile transformations, I help them to do what makes sense. I encourage them to challenge me when they think I am suggesting something that does not make sense.
Do what makes Lean-Agile Sense
Here is the rub. When I explain what makes sense, I talk in terms of "principle based" sense. Agile Sense provides a set of values and principles to guide our decisions and actions to achieve an Agile mindset. Lean Sense explains some of the process science of flow embodied in Agile methods. It is surprisingly easy to loose sight of this at key moments. Education and training on the Agile Manifesto and Lean Thinking is critical early on.The rest of the coaching engagement is a pragmatic application of Agile and Lean sense in decision making. This is a great way to help them learn and for me to make sure they understand.
Beware of Common Sense (and Be Aware of Culture)
Organizations and individuals will face challenges in an Agile transformation. They will struggle with decision making to solve these challenges. This struggle is good. But if they are not intentionally doing what makes Lean-Agile sense, they will inspect and adapt away from Agile. Teams tend to revert to solutions based on common sense in the organization. Common sense is the knowledge and experience most people have. It is based on what has "worked" in the past. It is remarkable how fast a group can slide back to what they did before based on common sense.
A Bias for Less
Common sense tells us we need more of the things on the right of the Manifesto. More documentation and following the plan. These are comfortable and safe. Agile sense encourages a bias for less on the right. Encourage a bias for less of the items on the right instead of more.
For example, as teams struggle understanding what to build, some managers want to solve the problem with more documentation. Agile Sense encourages progress towards working software. Start with getting getting better at collaboration to demonstrate software sooner.
Common sense tells us big batches lead to efficiencies of scale. Lean sense explains big batches lead to expensive delayed feedback and wasted effort that out weigh these efficiencies. Without fast feedback, we do not learn as we discover the solution.
Stay engaged in retrospectives and decision making. Look for common sense solutions.
- A bias for more of the things on the right side of the Manifesto
- A bias for bigger batches
- A bias for delay in feedback
Change the conversation with Agile and Lean sense. Promote a bias for less, not more.
Thursday, August 30, 2012
Jeff Patton gave a talk at Agile 2012 on "The Product Owner's Role". A couple of statements really resonated with me. "Discovery is what the product owner team does." and "The product owner's job is to provide impact and outcome." A film of a project I led came to mind.
A successful small company wanted a system to track and report performance of their field personnel. The VP of Operations had some clear ideas on what he wanted to see. We agreed to a short term 3 month contract to deliver and implement a pilot solution. Spoiler alert. The final product was very different from what he initially envisioned.
First, we had to develop an easy to use system to collect time data. We made a short list of the basic data we needed. We mocked up and demoed the data collection screen to a field services manager. He immediately asked why he had to enter information from the schedule that the company published in a spreadsheet. Discovery? We can use this to publish the schedule too. The project sponsor thought that was a real bonus and we were only a month into the project.
Next we had to validate the data. We could use payroll data to validate the time entry. Discovery? Maybe we could use the time entry to populate the payroll system. Turns out there were legal issues and that idea failed. Jeff also said in his talk that while many ideas fail, we learn from them. Later, we were able to run some nice payroll analysis report that really helped HR.
With data that was pretty easy to collect and validate, we were ready to produce management reports. We mocked up a report with some basic metrics giving the VP daily insight into his field operations. He was still skeptical. After all they had been trying to do this for several years with little success. He made some calls to a few reliable teams with poor performance for that week. Sure enough, they acknowledged they had some problems but would be back on track the next week. He was surprised by some high performing teams that he thought of as weaker. Sure enough, the teams were doing a great job and glad to hear that the boss knew it. This was powerful information.
Discovery? Maybe we could summarize by region? Maybe we could do some deeper analysis? Maybe we could track quality, customer feedback, pay performance bonuses...
Jeff also said that just building is soul crushing. Discovery is fun and rewarding. I agree. It was fun to discover and deliver a high impact business solution. And rewarding to help the people in the business. It did not hurt that we extended our contract for another 6 months.
Tuesday, August 7, 2012
Change is hard and many people do not have an appetite for it. Transitioning to Agile involves a lot of change: new thinking, processes, practices and tools.
So managers and Agile coaches provide training. They introduce the Agile Manifesto and Principles. They talk about ideas like Flow, cadence and light weight documentation. They introduce new practices and language. They even share success stories of how it works in other places.
Then a few teams are organized and the coaches help implement the new processes, practices and tools. We are on a roll. All this is going to lead to a better way of delivering value.
But we need to remember Agile is about individuals and interactions. We have to deal with the human side of change. Training and coaching on practices is necessary and important. But we can get too caught up in practices and slight the people. When working in larger organizations like I do, this can be an even bigger problem.
While facilitating training and coaching, try three things to help people experience how process and tools support interactions. This focus on people helps foster an appetite for change.
First, explain some benefits of an Agile Transformation this way.
- Business wants predictable and improved throughput
- Customers want quick lead times for quality product
- Teams want a good working environment where they can contribute and succeed
Second, challenge people to stop doing things or at least defer doing things. A lot of what people have always done is unnecessary especially those organizations focused on comprehensive documentation, contract negotiation and following a plan. The trick is helping people discover what to stop doing and what they can do instead to contribute.
Third, listen to what is not said and look into their eyes for comprehension to feel their fear and uncertainty. Resistance often stems from these emotions. With this understanding, we deal with resistance in a more productive way. Thanks to an old college professor for this bit of wisdom.
Foster an appetite for change in your Agile transformation.