Written by Andrew Fuqua Tuesday, 25 June 2013 08:10
Starting your agile transformation with a focus on practices is not an entirely bad idea, but with the wrong culture and structure, agile practices will be superficial. People will go through the motions. People will do agile things like have standups, demos, and planning meetings. You’ll have stories. It will look agile on the surface. But that’s all it will be — looks. There will be no substantive change, no stable teams, no control over Work-In-Process, no empowerment, and no predictability. You’ll have shallow collaboration, fault-finding and blame, and an unstable velocity. You’ll have no real support for agile or for improvement. You’ll get limited value out of your agile adoption efforts.
This isn’t the 1st time I’ve written negatively about mechanical agile and about how the agile values and culture are more important than the practices. While that is what I know to be true, there is more to the story.
So if starting with practices isn’t the best, where should we start? It’s not wise to start with culture either. Why not? CSM courses talk about practices and agile culture but when people go back to work they hit a structure that doesn’t support it, or they hit a command and control environment that doesn’t allow it. Attempts to change their culture are met with the realities of their organizational structure. Their structure is built around a different set of cultural expectations. The existing structure reinforces the old culture. Changing culture is hard, which is why many organizations start an agile transformation with practices.
Fortunately, deciding between culture and practices as the starting point is a false dichotomy. The place to start is with the structure.
Starting change with structure creates space and safety for practices to be put in place. At this point, we still can’t tackle culture head-on, and the practices will still be superficial at the start, but now there is support for the practices. You’ll have a shot at stable teams, at self-organization within the team, and enough empowerment for making reasonable commitments, leading to predictability. In this way, you can act your way into a new culture. Yes, I’m saying a new culture will emerge, but at this point, some intentional attention to shaping the culture is wise.
When I say structure, I have a few ideas in mind. The first is choosing between feature teams, component teams, services teams, or a mix. There is a great discussion on this topic on the LeadingAgile blog. Feature teams are great when you can have them, but an organization of size and complexity at some scale needs services or component teams added to the mix. Often, large organizations are already structured around component teams. We have to consider whether that is the best structure for their agile implementation.
Another idea I have in mind is just the stability of the team and whether it’s really a team, as opposed to a workgroup or project-group. For agile to work, we must have stable teams. Teams don’t work if management is often moving people around or if people are on multiple “teams”. Teams need to bond, to learn how to work together. Colocation is a huge help. Cross-functional is assumed.
Structure is among the most important concepts to nail for anyone scaling agile. At LeadingAgile we’ve been developing shared understanding on our approach. During this time, I’ve come to appreciate how much you can achieve with structure, along with practices, to create a team-based iterative and incremental delivery setup that is a precursor to agile. Once that is in place and we have some personal safety and delivery capability, some of the other things can begin to emerge, toward an agile culture. At a high level, that is our strategy for how to walk through the structure–practices–culture loop.Join the conversation. There are currently 6 comments.
Written by Jesse Fewell Tuesday, 18 June 2013 08:13
I’ve seen a pattern at a number of companies recently. It’s a pattern that demonstrates the danger of doing too many things at once. I call it the organizational death spiral.
Let’s say we have several product delivery teams in our organization, and that senior leadership have identified a handful of strategic initiatives that that are our next immediate priorities. Furthermore, let’s also assume that the estimates for each project add up to where we should be able to get them all done during the next quarter. Then we go upon our merry way building new products and services, just as management asked us to.
However, we know that challenges happen. For example, most companies simply are not organized into purely independent teams that can churn out products all by themselves. There’s almost always some kind of dependency on another team for those design specs, or some technical team for that fancy component, or some compliance team for full end-to-end behavior. Inevitably, this means at least a few teams have to shift their local priorities around on a regular basis in order to get anything done.
The problem is that juggling too many things at once decreases our focus, and slows down productivity. This is phenomenon is called “context switching”. There’s a ton of literature out there about how it slows down delivery, and makes us less predictable on delivering on deadlines.
As a result, product leaders are frustrated. We miss a date, which means we miss a market window, which means that project X is no longer worth the investment. So, leaders do what any mature leader should do: they kill the project, and replace it with project Y. It makes perfect strategic sense.
However, as soon as we make that change, we suffer more context switching and more delays in getting work done. Delivery teams become even more fragmented and even more frustrated (“Those executives keep changing their minds. They’re not committed to the long term and are only interested in the latest shiny object”).
After more project delays and slipped delivery dates, management decides “If we can’t get any one thing done on time, then we should work on everything at once.” Which leads to more fragmentation and context switching, which leads to poorer delivery.
…and it goes on…and on…and on.
Delivery organizations often assume that its all the product leadership’s fault for having shifting priorities. Meanwhile, leaders assume it’s all the fault of engineering, or IT, or service delivery for not organizing the work properly to get things done. The heart of the problem is that both organizations are interdependent. Specifically,
To stop the madness, the right people need to get into a room and declare “we doing only the single most important, top-most critical item right now. Then, with whatever extra capacity we have, we are going to repair our delivery organizations to handle more.”
It takes courage at multiple levels in the organization to do this. It requires that admission that we have a problem, and the iron will to do whatever it takes to fix the underlying disconnect between expectations and delivery against those expectations. Maybe you need to reallocate skillsets into different teams. Maybe you need to invest in fixing a quality problem. Maybe you need to implement a disciplined portfolio management competency.
But whatever medicine you take, the first step is to reconize you have to get off the crazy wheel of poor delivery impacting poor priorities, in turn impacting poor delivery.
What about you? Have you noticed that priorities and delivery BOTH impact each other?Join the conversation. There are currently 2 comments.
Written by Peter Callies Wednesday, 12 June 2013 02:54
Below is a fancy release burnup chart (click it to see the full image) that visually shows the work of a team from a recent release by a LeadingAgile client.
The red line effectively is the amount of risk. You can see that the team started the release with about 50% of their stories unsized, but consistently drove that down through the first half of the release.
You can see the impact of end-of-release hardening in the flatness of the shaded blue area on the right side of the chart.
In the shaded gray area, you can see the team performing backlog grooming, breaking down the work into estimated stories and even cutting scope mid-release (the gray area increases as the red line decreases).
The flatness of the shaded blue area early in the release shows the impact of a backlog that isn’t well-groomed, but as the team drove that red line down, the blue area takes on a more-consistent positive slope.
Cool stuff that demonstrates the impact of a groomed backlog and the effectiveness of a team.
Join the conversation. There are currently 3 comments.
Written by Isaac Hogue Tuesday, 4 June 2013 04:45
We encourage the teams we coach to keep their eye on the ball: Delivering a product that reaches a defined goal and thereby delivers value to its stakeholders in the most efficient, predictable and reliable way possible. This process of delivery frequently includes helping teams improve their internal product elaboration and development practices through the use of Behavior Driven Development (BDD) and Test Driven Development (TDD). And in doing so, it is my observation that there is a bit of confusion over the distinctions between how to focus teams on building the right software, and building the software right.
It seems that one of the key drivers for this confusion has to do with where Acceptance Test Driven Development (ATDD) fits into the development lifecycle. At present, BDD and ATDD both loosely describe a clarification process for iterating or incrementing around acceptance criteria for a given business goal that results in a just-in-time scenario or example-based specification.
What if we clarified things a bit…?
Perhaps we could reduce confusion around “building the right software… right” by redefining the specific meaning and places for BDD and ATDD as follows:
- Formalize the meaning of BDD around the practice of defining the “right” product through goal-oriented behaviors or scenarios.
- Formalize the meaning of ATDD around the practice of building the “right” product by connecting behaviors to automated acceptance tests.
How about the following as a high-level map for “building the right software… right”:
|Start with BDD to clarify the goal, defining behavior-based scenarios that will become acceptance criteria for scenario-oriented user stories|
|Then, (this is the redefinition) use ATDD as the iteration’s goal-oriented roadmap, where the delivery team transforms each behavior into a set of executable steps, or executable acceptance tests, using technologies such as FitNesse, Cucumber, or similar|
|And finally use TDD’s Red-Green-Clean cycles to develop a high quality product with the functionality required to see each step of the executable acceptance tests pass|
This approach clarifies the terms and provides a specific meaning and place in the development lifecycle for BDD, ATDD, and TDD. In my experience the above map has reduced confusion around how to “Build the right software… right”.
Let me know what you think. I’m eager to hear your thoughts and concerns around such a mapping.Join the conversation. There are currently 3 comments.
Written by Eric Kristfelt Wednesday, 29 May 2013 09:06
After working as a sales manager at two different Agile organizations I am often asked if sales can be Agile, and if so, how is it implemented?
At my previous company, several departments chose to align with the development team’s 2-week sprints/builds. The marketing department started using a Kanban/Scrum approach, and it made sense as the marketing goals naturally aligned with the builds and releases. But would a Kanban/Scrum approach make sense for the Sales team? And if it makes sense, where should we start?
Step 1: Training: It is important for the teams to be trained on Agile/Scrum so that they understand the methodology and the goals. It can help everyone if the sales team begins to gain a better understanding of the development cycle. One challenge we faced was determining how to set-up our teams. Typically, sales professionals are viewed as individual contributors and not part of a team. We found that management had more challenges moving to a team approach than the sales professionals. Successful sales people are accustomed to working within a team given today’s complex sales models — which mean working with everyone from sales engineers to consultants to management and even Legal teams. Most individual contributors realize that this is the reality of today’s business.
Step 2: Stand up: Stand ups allow teams to adapt and react quickly to how the process is working for customers and external teams. Stand ups are a natural for sales teams; most sales people are impatient and like short meetings that are to the point, and that can help them resolve problems and focus on accomplishments. At my former company, if a particular impediment was outside the scope of the sales team, we might invite members from other teams to attend the next stand up. Our sales people hated being required to listen to others dig into their own issues, so moving longer discussions to “post meeting” status was popular among our sales people.
Step 3: Sprints and Retrospectives: For sales, the sprint cycle may be much longer than recommended for a typical development team, but it’s important for sales managers to follow the sprint structure. Sales teams often work on monthly goals, so that’s how we set up our sprints–much longer than a development sprint– but a period of time that made sense for our goals. We could determine what we accomplished the previous month, review impediments that were not resolved, and determine our goals for the upcoming month/quarter. These types of reviews are very natural for sales teams; although a step that many skip in the busy day-to-day pursuit of closing deals.
Step 4: Re-interpreting Product Backlog: Our team implemented an EPIC board (Customers) and Tasks were set up as “backlog items” with a “pending”, “in-progress”, or “completed” status. Suddenly, the entire sales and sales management team had a clear visual for the enormity of tasks during the iteration. Velocity (or, in this case, expected sales per iteration) was available for inspection and adaption. This approach allowed the sales team to focus on their workload, and it helped minimize distractions from management. Even the engineering teams would walk by the boards and understand what was going on with accounts and opportunities.
Challenges to Agile Sales Models:
Switching to Agile wasn’t easy on the management team. How would they hold individual sales people responsible? How would they compensate each sales rep? What if someone on the team wasn’t making enough calls? Many executives thought the stand up meetings would be too short to accomplish all of their weekly goals.
The company I worked for set up a true sales scrum team with monthly iterations. The teams hit the goals set up by management, and for 6 months we iterated and worked as a Scrum Sales Team. From a sales attainment perspective, it was the most successful the team had ever been.
For reasons I still fail to understand, the company restructured itself, and the Scrum Sales Teams were eliminated, but not before we realized the power of Agile within sales. It was the first time that entire teams reached quotas assigned to the company, as opposed to just individual sales contributors. Onboarding and ramping up new reps happened more quickly; most likely due to interfacing with successful senior reps.
By following the steps in Scrum, management learned that sales can lend itself easily to an Agile environment. Individuals found that this shared work model led to more consistent revenue and compensation in addition to a more even workload. No longer did the “sales stars” work much harder than everyone else. Each team member focused on his/her own domain expertise.
While we found it difficult to find “Renaissance sales people”, we were able to create the perfect sales person by matching skills, or by filling voids by marrying strengths and weaknesses of individuals within every given team.
Scrum also allowed a better quality of life: Sales teams had time to enjoy vacation or family time because the team could step in to support customers while any single member was away. Our teams were self-managing, and the sales manager acted like a Product Owner as opposed to a Scrum Master.
Let me know your thoughts and experiences implementing an Agile sales model.
–Eric KristfeltJoin the conversation. There are currently 3 comments.
Upcoming Training Classes
2-Day ScrumAlliance CourseCertified ScrumMaster(Sold Out)
December 2-3 Orlando, FL
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep
December 5-6 Alpharetta, GA
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep (Sold Out)
December 9-10 Washington, DC
2-Day ScrumAlliance CourseCertified ScrumMaster
December 12-13 Alpharetta, GA
2-Day ScrumAlliance CourseCertified ScrumMaster
December 16-17 Washington, DC
2-Day PMI Course (21 PDUs)PMI-ACP Exam Prep
December 19-20 Westminster, CO
2-Day ScrumAlliance CourseCertified ScrumMaster
February 20-21 Alpharetta, GA