At LitheSpeed, giving back to the community is one of our core values. From lending a helping hand to folks temporarily out of employment, to contributing to learning events, our team is always finding ways to “pay-it-forward.”
Over the past decade, giving back to the community through speaking at agile and project management events has been pretty constant. More recently, growing out of the work done by Bob Payne in establishing Agile DC, we have begun hosting our own events. Over the past three years, we’ve established a twice-yearly event cadence for larger events with Lean+Agile DC in Spring and the Agile DC Executive Summit in Fall. We also host the Lean Enterprise Meetup monthly at our Herndon, VA headquarters.
2014’s Agile DC Executive Summit was a great event, and we enjoyed learning from Max Keeler from The Motley Fool, Christina Handley and Sujatha Augustine from the Millenium Challenge Corporation, Mark Perine from Marriott, Gill Haus and Elliot Susel from AOL, and Dave Merkel from FireEye/Mandiant. Watch the video recap below.
This year, Sanjiv Augustine is the volunteer Chair of the Agile Executive Forum. In this role, Sanjiv is contributing lessons learned from hosting LitheSpeed’s own executive summits.
For those in the DC Metro area, we hope you can join us at these upcoming events:
For our friends outside of the DC Metro area, we will be at these events:
May, 2015: Global Scrum Gathering, Phoenix, AZ
May, 2015: Agile Austin 2015, Austin, TX
June 2015: Agile Development Conference West, Las Vegas, NV
June 2015: PMI Houston Expo, Houston, TX
June 2015: PMI Silver Spring, Silver Spring, MD
August 2015: Agile 2015, National Harbor, MD
November 2015: Agile Development Conference East, Orlando, FL
With the buzz around Continuous Delivery (CD) these days it might seem like an antiquated notion to even speak of, let alone write about Continuous Integration (CI). However, in the many conversations we’ve had with organizations looking to implement CD or in the midst of an implementation (and stumbling), it has become rather clear to us that there exists a wide chasm that needs to be bridged on the foundational aspects that support an organization’s desire to adopt CD. CI is a key supporting construct whose principles are still not understood/implemented with sufficient clarity, and hence worth a revisit.
Read the rest of Raj Indugula’s blog post on the VersionOne web site.
Sanjiv Augustine was recently interviewed by Josiah Renaudin of Sticky Minds about the critical role of the Product Owner. Sanjiv discusses the Product Owner role saying that it, ’sits at the junction between delivery and discovery’ and studies the product owner, a role in a Scrum team that works with customers, defines the product, prioritizes requirements and works with delivery teams.
Read the whole article to hear Sanjiv’s take on the barriers that hold people back from development success and the tools and techniques he uses in his Product Owner workshops to to teach students to overcome those barriers.
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.