Discovery is Fun
Last Updated on Friday, 16 November 2012 01:27 Written by Dean Stevens Thursday, 30 August 2012 09:00
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.Learn More
Team WIKISPEED at Agile 2012
Last Updated on Friday, 16 November 2012 01:24 Written by Derek Huether Tuesday, 28 August 2012 10:41
Regardless of where I coach or teach, there is always someone who approaches me and says something like, “Agile is great for software projects but what about projects that aren’t software related?” When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I’ll save those stories for another time). I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize.
While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)
Here is some back story from a 2011 press release: Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team’s SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.
Joe was able to build his first functional prototype in just three months. The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995. The reason auto manufacturers are so slow to “better” their products is because change is very expensive for them. It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles. Before Object-oriented programming methods were introduced, software teams used to operate much the same way.
By modularizing how we build software, we’re able to shorten our development cycles down to days. By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want. We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos. My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.
Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers? Joe and his team have a car that has a development cycle of seven days. They do this by modularizing the car. They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck. All of this allows them to make changes and develop quickly.
The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts. This helps them lower waste (Lean). Next time you say you can’t afford to do test-driven development, think about that. They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that. Pairing also helps lower the need for most types of documentation. If everyone has a shared understanding, you have less need for it. They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).
So, do you still think Agile is only for software projects? The fact that they use 7 days sprints on hardware, when I hear people say they can’t do anything less than 30-days on software, just goes to show you where there is the will there is a way.Learn More
Effective Risk Management That Isn’t Boring
Last Updated on Tuesday, 4 February 2014 12:39 Written by Jesse Fewell Friday, 24 August 2012 04:00
Last week at Agile 2012, there were a couple Risk Management talks that blew my mind. I was already comfortable with the notion that Agile methods offer a set of effective IMPLICIT risk management practices (e.g. iterative learning cycles, fully tested iteration increments). But this past week, I learned the community is beginning to mature a set of EXPLICIT risk management practices that can be embedded in your Agile methods.
Mike Griffiths shared his experiments with using collaboration games to improve Risk Management practices. He has a multi-part blog series that goes through the approach in detail, but the most important can be summarized in 3 points. Meanwhile, LeadingAgile’s very own Dennis Stevens had a talk where he challenged people to move beyond 1-dimensional thinking. Here is my summary of the key points from both talks.
Effective Risk Management Techniques
Make risk planning more engaging. In his talk, Mike asserted that we need to get beyond the idea that Risk Management has to be boring academic exercise. He does this by renaming the standard risk management processes to be more playful. “Risk Identification” becomes “Find Friends and Foes”. “Qualitative Risk Management” becomes “Post Your Ad”, where risks look more like a job board. This helps us get over the anxiety of being perfect or technically correct.
Make risk planning more holistic. Dennis suggested we involved multiple disciplines in risk analysis, rather than just the ivory tower project manager. Technical people, operations people, HR people, all need to be a part of the conversation. He also highlighted our tendency to go straight into the weeds (“IF the shipment of servers is late, THEN our testers will be late getting started”). Instead, Dennis proposed a multi-tiered taxonomy for thinking about risk at progressively higher levels. Specifically, a Risk Category (e.g Security) will cover many different Risk Drivers (e.g. Fraudulent Transactions), which will in turn unearth the Risk Events (“IF a customer deposits More people thinking about risk at more levels.
Make risk planning more visual. Mike shows a few examples of hands-on collaboration games for performing the risk management processes. This moves the risk conversation into a more whole-brained activity, where both left and right hemisphere activities are engaged. Also, it keeps the risks front-and-center in our minds as we perform the project, rather than having them archived in a spreadsheet somewhere.
What about you: What EXPLICIT risk management techniques do you add into your Agile projects?
The Two Faces of Agile
Last Updated on Thursday, 15 November 2012 12:49 Written by Mike Cottmeyer Tuesday, 21 August 2012 07:50
Some folks are using agile to invent. They are trying to figure out the right products to build for markets that don’t even know what they want. They are experimenting, learning, and adapting their approach based on super-fast feedback cycles… and the outcomes, the products they are trying to build, are emergent. The end goal isn’t necessarily clear at the start.
Other folks are using agile differently.
These guys are also trying to figure out the right products to build, but their markets have a predetermined notion of what to expect. These teams also experiment, and learn, and adapt their approach on super-fast feedback cycles… but the outcomes, the products they are trying to build, need to converge around set expectations and emergent outcomes aren’t always valued.
To effectively introduce agile into your organization… you need to know what kind of organization you are living in. An organization that needs emergent outcomes may reject keeping a fine grained story backlog or doing any kind of long term release planning. Likewise, companies that need convergent outcomes may reject sitting with a client and figuring it out as you go.
It always, always, always comes down to context.
Both an emergent approach and a convergent approach can work just fine, depending on your particular context. The trick is knowing the goals of your business and adapting your language and approach accordingly. If you are struggling to get senior leadership to see the merits of agile, maybe your are selling emergence when that’s not what your execs are really buying.Learn More
Beyond Functional Silos with Communities of Practice – Agile 2012 Slide Deck
Last Updated on Thursday, 15 November 2012 12:49 Written by Mike Cottmeyer Saturday, 18 August 2012 09:36
We had over 100 sign up for this one – and the room was completely full. We talked about using Communities of Practice to support Agile adoption and sustainability in the Enterprise. We went through a Community of Practice charter exercise. Again, over a third of the people in the room said they would apply this to their groups when they got back.Learn More