LitheSpeed received a question from a student about an issue their company was facing during project planning. We believe this issue is a common one and therefore decided to share the conversation.
The company in question was experiencing growing pains, especially when it came to planning and forecasting. In their experience, the high level planning done months before a project began did not match the lower level, detailed planning done right before the start of each project. Large changes in cost and scope right before project starts made it hard to manage business expectations and set predictable delivery dates.
Arlen Bankston, LitheSpeed’s managing partner, had this advice:
Agile planning largely relies upon a rearview mirror approach, and in longer-term budgeting activities, this is going to be the most reliable method. Velocity is a simple local example of this; by paying attention to the output they’ve actually achieved recently, teams get a good average idea of their capacity over time. You quite often see consistent overcommitment by teams who ignore their previous velocities (or fiddle with the estimates too much) when forecasting future sprints. This empirical approach can also work at higher levels for business planning.
A local client of ours named Opower tried an interesting technique; they let business managers “buy” time from their teams by using tokens, where a single token represented the output of any given team over a single two-week sprint (the teams were similar enough that this was effective). They distributed the tokens over various stakeholder groups that requested development time, and were able to see that while they had roughly 100 tokens available the first year (five teams, ~20 sprints), the business demand for high priority efforts ended up closer to 200. So they hired more people, thus matching observed demand to real capacity. The key is that they maintained the discipline to keep teams stable and dedicated over time, rather than multiplexing them and moving people around. Many companies have very little idea of their true capacity, because constant adjustment of resource allocations makes it extremely fuzzy. They tell some of this story in an article they wrote for HBR.
Another core idea is that both planning and estimation work much better when you actually understand the work, which usually requires some reasonably in-depth analysis done by whomever is actually going to execute. You’ve already seen this, as your localized three-day sessions produce much better forecasts than the far-removed business side’s. However, as waiting until you’re starting the work to get a sense of its likely cost is unpalatable for the business, you can combine this with some projections based on something like the past few months’ output from the teams in question to get a decent mid- to long-term forecast for budgeting purposes. Put simply, whatever you spent last quarter will often be quite similar to what you’ll spend this one, as long as you’re not substantially changing team composition or making capital expenditures.
So, a few direct tips to sum this up:
- Keep teams as stable as possible. This makes everything more accurate and consistent, notably velocity, and will more importantly tend to improve productivity and collaboration. Bring work to established teams, rather than establishing teams around projects.
- Match estimation granularity to the timeframe:
- For project portfolio management and ROI projections, use something very high level like S/M/L/XL, based on projects of similar budgets in the past.
- For release planning in the 1-3 month timeframe, use something like story points or story count, but decompose anything larger than ~2 weeks of effort (roughly 8 points, if 1 point is similar to a day), as large things tend to be larger than you expect once you break them down.
- For sprint planning, keep things to just a few days of effort, likely 1 or 2 points (or just use story count and a range, such as 6-8 stories/sprint).
- Favor ongoing engagement over long-term projections. Encourage your business stakeholders to stay in the loop and ensure them that you won’t allow any nasty surprises to sneak up on them and will provide frequent updates and more accurate forecasts over time. Don’t make promises many months out, because you won’t be able to keep them.
- Consider incremental funding strategies. The expectation that business planning for software projects actually works over a whole year is a thoroughly debunked artifact of waterfall project management, as evidenced by all the time organizations spend re-planning following annual budgeting efforts. The wiser approach is to keep a sense of how much you need to spend total, then allocate as time proceeds based on current needs, which gives the business more flexibility in managing both their budgets and the development efforts they’re funding.
You can see some current lines of thinking on this and budgeting in general here: http://bbrt.org/.
LitheSpeed is excited to announce that Sanjiv Augustine will chair the Agile Alliance’s Agile2015’s Agile Executive Forum. Join a select group of executives and top Agile leaders for an intensive one-day opportunity to explore the latest in strategic thinking in Lean and Agile practices and principles applied towards building the Lean Enterprise. Lean Enterprises have the signicant competitive ability to respond rapidly to change.
The Forum is structured as a combination of:
- Keynotes from top performers
- Short presentations spotlighting innovative success stories and transformation challenges
- Breakout discussions with exploration and problem resolution
- Networking and community-building events
- A no-sales policy is in place to keep your thinking clear
See the AEF site for more details, and to register: http://execforum.agilealliance.org.
Susana Esparza interviews Arlen Bankston on the process of Lean/Agile Discovery. Agile helps us “build the thing right” and lean discovery helps us “build the right thing“. Teams are increasingly finding that these things must be done in conjunction to truly maximize the flow of value.
We make choices or trade-offs everyday.
Run out of butter? No problem..use applesauce for a recipe. Don’t have time to go to the gym? Physically run to pick up the kids from school or eat a healthier lunch.
As you can see from my examples, in addition to working part-time for LitheSpeed I am also a mom. Maintaining my home life (I have three children) and finding the time to get my work done is sometimes a challenge. Any working parent knows that.
In addition to these work and family responsibilities, I am also the Parent Teacher Association (PTA) President at my kids’ school, Herndon Elementary School. Our school is a Title 1 school, which means that over 50% of the children are on a free lunch program. This makes fundraising a challenge. In the past, the school sold wrapping paper and held a silent auction to raise money for field trips, assemblies and other activities. In recent years, these sales have been decreasing…for obvious reasons.
In response, we have had to think outside the box, become more agile with our fundraising methods, and run some experiments.
This year we started a corporate sponsorship program. Local companies can donate to our school in exchange for marketing on the PTA Facebook site or in our monthly newsletter; and they can make appearances at school functions.
We also began using a program called 4 Our School. The service allows shoppers to click through a link (http://www.4ourschool.com) and choose Herndon Elementary School to get to a list of retailers such as Amazon, eBay, BestBuy, Kohl’s and Shutterfly. Once they click the link, they shop as they normally would and the retailers donate a percentage of their purchases to our school.
We have yet to see whether we can sustain the activities that enrich our students’ lives with these new fundraising methods. Next year, the next PTA Board might have to come up with new fundraising ideas and experiments.
I know from LitheSpeed’s CSM class that a year is way too long for a Sprint, but sometimes that is life. And we do what we can with the decisions that we face. LitheSpeed trains people to be agile in the workplace, but life teaches us to be agile for the rest of the day.
What?!?! There’s no agenda? This was my initial reaction when I looked at the agenda on the 2015 Agile Open Northwest site. At first, I thought that this was the craziest thing ever. How in the world can you get over 100 people organized if you don’t have an agenda? Then when I thought about it, it was the most amazing thing ever. Typically before a conference, I spend hours scouring the session agendas and descriptions. I’ll get my highlighter out and color over all of the sessions that I want to attend. But, this time, a huge weight was lifted off of my shoulders. I get to pick what interests me at that exact moment. It was brilliant! My colleague Bob and I were in the middle of creating a game that we wanted to submit to a future conference. Bob had the great idea of using the Open space concept to get real time feedback on the draft version of the game we had created. Another brilliant idea! This made me look forward to the conference even more.
Once I got there, I was amazed at the physical space! The organizers did an amazing job picking a location that would foster conversation and openness. Picture a space with minimal walls, concrete floors, exposed duct work and LOTS of coffee. It really was perfect. In the center of the space, there was chairs set up in a circle. In the middle of the circle were several large pieces of paper and markers. All of you open spacers know the drill (so feel free to skip to the next paragraph if you know this). Everyone that wanted to wrote down a topic that they were interested in or that they wanted to share on the large piece of paper. My card said “Who wants to play a game?” When it was my turn, I explained what it was that I wanted to do and invited people to play with me. I selected a timeslot and room and BOOM! Instant session. Just add markers.
What happened next was so incredibly cool. When I went to the room, about 10 other people who REALLY wanted to help me joined in on the conversation. They came from all different backgrounds. Developers, Scrum Masters, Gamers. . I loved it. We threw some flip chart paper up on the wall and just started brainstorming. They helped me come up with tons of content for our game and even made suggestions for future versions. Once I had that information, I thought “I’m going to do this again tomorrow!” That night, my fiancé and I spent a lot of time making a paper version of the game (talk about just in time design). So the next day, I did the same thing. I created another session. But, this time, we played the game.
Overall, I really fell in love with the open space concept. What I truly loved were the 5 principles:
- Whoever comes are the right people.
- Whatever happens is the only thing that could have.
- Whenever it starts is the right time.
- Whenever it’s over, it’s over.
- Wherever it happens is the right place.
It left me feeling like I was in control of what I wanted to learn and to teach. I felt like the conference had just enough guardrails without getting too prescriptive. I would definitely recommend an open space conference if you haven’t been.
Or you could try AONW 2016!
Another idea….come to LitheSpeed’s Agile Games Day on March 20th. Play is key to learning for people, it provides an enjoyable, low consequence environment to try out new ideas and explore new modes of interaction. Our experience as trainers and mentors and the research is showing that games are not just for kids anymore. Find out more information.
One common aspect of agile adoptions are groups tasked with leading and supporting the effort. I have done a presentation that covers this at a high level, which is available in textual format here. Sanjiv’s book also covers this to some degree. Below are a few high level points to keep in mind if you’re considering forming an Agile Working Group or Agile Steering Committee.
The Agile Working Group is the mover and shaker of transformation efforts, providing a central point of support for the training, coaching and change efforts in general. It’s most common failure mode is a lack of true commitment. The group should be set up something like an agile team, with:
- Reasonable time and focus dedication for at least core members
- Regular meeting cadence and location
- Careful WIP limiting
- Consistent focus on tangible deliveries/progress
- Demonstrations of deliverables to customers
Without such support in place, little happens while everyone is busy with their day jobs, and the group simply dies of attrition. I like linking these working groups to active coaches as well, since they generally already have the time, knowledge and interest necessary to imbue the group with positive energy and maintain momentum.
The Agile Leadership Team sets goals, clears obstacles and celebrates progress in the early days, helping to show that the company as a whole is behind the effort. However, they become truly critical when the organization is ready for big changes (e.g. different budgeting/financing structures, performance review models, portfolio management procedures etc). The working group would still tend to do the heavy lifting in terms of formulating new plans, but the leadership team must be well engaged for transformations where true business impact is desired beyond just a handful of individual teams.
Both teams are meant to be transitional, and their missions and compositions alike can be expected to change over time alongside the organization’s needs and challenges. Eventually, management and governance structures will be in place, coaching and training support structures will be well established, and more localized assistance can to a large degree replace the centralized change management effort.
Henrik Kniberg in his excellent YouTube Video Agile Product Ownership points out that teams face three competing forces:
– Build the Right thing
– Build the thing Right
– Build the thing Fast (i.e. shorten the feedback cycle)
All three are equally important, and they all reinforce each other, yet it seems as though since the agile manifesto was written, building the thing right and building the thing fast have gotten a lot of the attention as these are mostly impacted by improving development practices and collaboration, which is primarily the focus of the various agile approaches (Scrum, Extreme Programming, etc.)
When it comes to building the right thing, it seems as though an unstated assumption has always been “the Product Owner/Onsite Customer knows what that is.” Trouble is, the people who may be the most desirable to act as a product owner or onsite customer in terms of their authority to make decisions on what the right thing to build is either do not have the time, or the inclination, to spend the amount of time with a time required to effectively provide the necessary guidance.
To make things potentially even more interesting is that there are (at last count) at least three different skill sets that all tend to center around figuring out the right thing to build. Each skill set is well suited for a given context, and less applicable in others and as a result tend to overlap quite a bit. On top of that most people who consider themselves a practitioner in one of those three skills sets rarely identify the other skill sets as useful, even though they practice many of the same skills. Those skill sets are product management, user experience, and business analysis.
There is quite a bit of overlap between business analysis and product management, primarily because they apply a similar set of skills in different contexts – Product Management for software products and business analysis for efforts that are not directly related to an organization’s end products, such as processes or systems that support those processes. There is a substantial set of Product Management that does not overlap with business analysis such as focus on profit and loss and delving into the market aspects of a product.
Business Analysis and User Experience provide an interesting comparison, they solve the same problem, but take fairly different approaches to solve it. Business Analysis describes the right thing to build using an analysis mindset and focuses more on the needs of end customers (the people paying for a change) whereas user experience tends to solve the problem with a design perspective and places more emphasis on the end user of the solution.
Again, neither perspective is right or wrong, and in many cases both perspectives are needed to a greater or lesser extent depending on the context.
So you have multiple ways to identify the right thing to build, with disagreement from practitioners around whether they actually do the same thing and yet a lot of overlap between the approaches. It would be helpful if there was a hand tag that you could use to refer to the activity of figuring out the right thing to build that incorporates the useful aspects of product management, business analysis and user experience but is not exclusive.
The International Consortium of Agile, (ICAgile) in an attempt to organize all the knowledge related to agile into tracks, applied the term “Value Management” to software development as a way of pulling together the disparate ways of figuring out the right thing to build into some sort of coherent whole.
ICAgile did not define specifically what Value Management specifically means, but introduced the Value Management Track as follows:
“The Agile Value Management track emphasizes customer-focused approaches and practices to maximize value delivery at various levels within organizations. The learning objectives highlight concepts around organizational alignment, adaptive planning, establishment of value teams to set priorities, and techniques for spreading value-based approaches such as product roadmapping, progressive elaboration, and frequent cross-program communication.”
Here’s how I like to think of Value Management as applied to an agile setting (although hopefully you are doing these things regardless of what approach you are using.
- Understand stakeholder needs
- Determine if the need is worth satisfying
- Determine the best solution to satisfy it
- Build a shared understanding of the solution
- Validate the need was satisfied
This concept of value management is understanding the next most important set of needs in the marketplace or in your business and finding that in a way that you can work through this collaborative process of getting the best solution to the problem delivered in the nearest term possible. So it’s not just about taking orders, it’s about balancing capability and capacity against the next most important things to the business. It’s much bigger than order taking and producing documents.
The Agile Value Management class that B2T Training and Lithespeed are partnering to deliver shows how to apply business analysis techniques as well as a few techniques from Product Management and User Experience to make sure your team is building the right thing for your organization.
My fiancé and I recently bought an older home built in the early 1900s. Despite it’s age, it has a lot of modern amenities. The previous owners did a great job updating the place. The only thing that I do not like about the house is the kitchen. Don’t get me wrong. It is a REALLY nice kitchen. But, it’s just not our style. So, we decided that we would give it a face-lift and make it more of our own.
The first step in our renovation process was to start small and change out the light fixtures above the island. If you’re into super contemporary fixtures, man, this was the light for you. I on the other hand, am more traditional and wanted that thing out. We met with a local contractor because the job seemed bigger than just taking it down and putting up something new, and we were right. It required dry wall work, patching, and other things I know nothing about.
The contractor came over on a day that I was at home. I thought I could just hang out in the living room and get some work done while he played Kool in the Gang in the kitchen to pass the time. I quickly figured out that wasn’t the best approach.
Thankfully, our contractor wanted me involved in every step of the way. At first, I thought, “I don’t have time for this, I have other stuff to do!” But then I thought, “wait a minute! I’m acting much like a product owner here and he’s acting like a development team. Maybe I should go along with this?” Our contractor started measuring where the lights should go. As he did this, he constantly asked “is this what you want?” It was almost like we were doing continuous development and testing together. After we measured everything and held the lights up, we realized that it wasn’t what I wanted. The requirements had changed and we were quickly able to respond to that change without realizing it at the end.
I also made sure my stakeholder, AKA, my fiancé, was getting demos throughout the process. I sent him pictures of our progress together and it was great. He was also able to give feedback as well, which I prioritized for our contractor.
All in all, I’m glad that I was able to collaborate with our contractor. The end product had the best quality and I’m really happy with the results. Can your product owner say that?
From Lean management, we’ve heard the exhortation to, “go to the gemba.”
Getting management to perform a gemba walk is gaining popularity in agile circles, and of course, has been a key Lean technique for decades. As this excellent article points out, the gemba walk is not strolling around and glad handing people.
How important is it to connect management with the gemba, or “real place” where work is done?
To fully appreciate the answer consider the alternative from the world of auto manufacturing. For years, executives in Detroit insulated themselves from the shop floor – their gemba. From the Seattle Times:
For generations, the 14th floor of the General Motors Corp. headquarters, with its thick carpets, mahogany walls and electronically controlled glass doors, has been the ultimate symbol of power at the world’s largest company. Access was by invitation only.
Top executives were sealed off from the rest of the GM work force. Chauffeured into the basement garage, GM’s leaders were whisked by private elevator to the 14th floor’s executive row, where their meals were catered in a private dining room.
The 14th floor was an essential part of the corporate culture that shaped GM – for better, and recently for worse – for more than half a century. Now, as GM’s board and a new team of managers struggle to make the company more competitive, they are beginning by destroying the mystique of the fabled executive floor, in an effort to change a corporate culture marked by insularity and inbred management.
The results, as we American taxpayers know too well, were disastrously painful, culminating in the implosion and subsequent auto bailout in 2008. So, how did Detroit’s new ‘C’ suite go about fixing their massive mess and get out of bankruptcy?
Sergio Marchionne, the CEO of Fiat and Chrysler took several bold steps to turn Chrysler around. One of them was to forgo the remote chairman’s office for the shop floor. The old office is now an empty “tourist trap.”
A great example of go to the gemba, indeed…check it out in the 60 Minutes clip below.
Part of the mission at LitheSpeed is to reach back to the community in some small manner, each of us committed to that notion in our own unique way. The thought of engaging with kids resonated with us, but of course, we didn’t quite know where to begin. Ideas were tossed around, and soon, one of them took root and we put forth our maiden venture – a Kids Programming Workshop. An experiment really, so we extended the invitation to our own kids and some of their friends. We limited the group to about 20 kids (8 to 12 year olds).
The platform of choice for the workshop was Scratch, a fun and intuitive visual programming tool conceived of at MIT and provided free of charge. Scratch helps kids to think creatively, reason systematically and create their own stories, games and animation using typical programming constructs and commands that can be snapped together like LEGO-blocks.
We set up some laptops in our training facility and picked a Saturday to run this ½ day session, quite unsure of how it was going to play out. The agenda was quite straightforward – a short introduction, followed by time-boxed immersive exercises conducted in pairs, followed by a showcase. Heck, even if it were a train wreck, there was pizza at the end to make it all right!
We need not have been so anxious as to the outcome, because it was a blast! Amongst the kids were some seasoned Scratch programmers who not only demonstrated their talent in creating expressive, engaging games, but also impressed us with their willingness to guide and help the novices along, and the hubbub of active learning and problem solving within the space was simply exhilarating. It was amazing to see the kids take to it so readily and so enthusiastically.
Buoyed by the success of this pilot, we are committed to broadening the reach and scope of similar initiatives this year. Try it for yourself and see if you catch the itch to Scratch.