Links to Article Series and Key Posts
Here’s the starting links for some article series and key posts. Enjoy!
- The Starting Problem Series
- Keynote Speech – Four Views of Enterprise Agility
- Agile Organizational Design
- Applying Scaled Agile Framework (SAFe) to Companies with Small Value Streams
- Seeing the World Through Agile-Colored Glasses (Scrum Alliance article)
- The Big Lever – Project vs. Release Orientation (Scrum Alliance article)
- Management Innovation to Achieve Continuous Business Value Delivery (presentation at the Philly ETE conference)
The Starting Problem Series – The Problem with Agile Recipe Books
Ever tried getting a recipe book and recreating your favorite dish made by your favorite chef? You have followed all the instructions, gotten the right ingredients, and channeled your inner Emeril, but the dish still does not come out a 5-star meal. What has this got to do with agile transformation? Read on.
You heard a colleague boast of results they achieved using agile methodologies at her last job, or maybe your boss just asked you to drive agility into your organization. To get the ball rolling, you are now reading a book on agile requirements and doing lots of other research on agile frameworks. You have officially embarked on your agile transformation journey. Let’s assume you are in an organization and at a level in the pecking order that you can influence change. Also, let’s assume that you have convinced your peers to support you in this transformation. Where do you begin? What is the recipe to agile transformation?
Agile transformation is much more than recipe, ingredients and following instructions. The journey is about being open to experiencing the transformation, giving up control and exploring new boundaries of leadership. The prize – an organization so self-organizing and committed to delivery that every associate enjoys coming to work like nowhere else they have been!
You will know if your transformation is heading in the right direction when, for example, a developer makes suggestions about changing your release processes, drives it through your organization and his plans and ambitions are not held back by the “owner” of release management process. This, my friend, will create the joy to be at work. Your organization will rejoice as examples like this become common place and they start realizing this is the sort of work place they want to be..
Here are some ingredients that may be part of your recipe:
1) Talk to your leaders, listen to their concerns – their leadership is most valuable to make the transformation successful. Engage your leaders with delivery responsibilities and map these responsibilities to the outcomes that are expected. Publicize these outcomes within your organization, support your leaders and hold them accountable for timely progress. Your leaders must deliver real change – not reports or a new reporting mechanisms – rather real change that impacts the way people work.
2) Cut the red tape – every process that does not add direct value to the customer is waste – you can bet that you have plenty of waste in your system. Create a backlog of this waste, prioritize based on the impact of eliminating the waste, and execute the backlog by putting automation or a leaner process in place. One at a time – do it.
3) Set money aside to invest in DevOps – free up your developers to focus on one thing – delighting your customers with flawless software. In other words, let them be software craftsmen. Get your developers and testers out of the business of creating manual builds, deploys and manual testing.
4) Get your best people to build your technical practice. Let your architects solve the biggest technical hurdle – getting your development operations to flow. Ensure that your technical practice delivers continuous feedback to all stakeholders involved.
5) Bring an über transformation specialist, or “transformation chef” onboard – a dedicated, experienced agile transformation specialist. There is no substitute for this ingredient. The reasons are simple. First, the transformation obstacles this “chef” has experienced do not need to be repeated by your organization – avoid unnecessary pain where possible. Second, the “chef” can help you plan out your agile journey and some near-to-long term waypoints.
While there are many outcomes to be expected, exercise good judgment in picking your “transformation chef”, the recipe and the ingredients. Imagine if your executive team is expecting a gourmet meal from your transformation and you end up serving them a Big Mac! You might find yourself working at the golden arches!
The Starting Problem Series – Realistic Agile Transformation Expectations
Expectations are everything. If you set a goal, communicate it and then meet it, your team is thrilled and so are your stakeholders.
Organizations quite often operate with their collective head in the sand and have self-proclaimed “optimized” internal processes and are therefore not looking for critical feedback to make improvements. Over a period of time, they become dysfunctional. However, since this decay in processes and capabilities is gradual, no one internally feels the pain or the need to change. It’s almost like the frog that is put in cold water and then the pot is set to boil. Alas, it’s too late for the frog to find out how close it is to its end. It usually takes a new leader or a costly error that causes organizations to change their product delivery processes and adopt agile methodologies. Usually, these errors force a change in leadership and the new leadership drives change in the organization.
When an organization gets into the groove of transformation, leadership demands root cause analysis and inevitably, a lot of questioning of current processes and procedures happens. A common problem during this phase is that some people utilize this opportunity to look for “organizational scapegoats” who are believed to be the root causes for these problems, with little or no appreciation for why the process had been put in place. It usually takes a long time for processes to be embedded in an organization and the transformation period leads to some unreasonable expectations for effective process changes to be realized in a very short period of time. All the while, expectations of in-flight projects are to move as fast if not faster than before as soon as the transformation starts.
Agility and transformation can bring out the best or worst of your organization. If your transformation is guided correctly and the focus is on answering the 5 Why’s, you will arrive at the core processes that need to be re-engineered. Surely, there will also be a few laggards in the organization who may not be on board with transformation, and hence may have to depart from the organization. This should not be surprising as not every one in every organization can be assimilated into an agile organization. Agile also amplifies the needs of your organization’s demands – especially from “traditional cost centers” – development, QA, and infrastructure. Suddenly there is need of investment for the right resources and to invest in new tools and infrastructure to promote your organization’s agility. It is key for leaders focus on lean and then automation – focus on getting to short-term results with a long-term success strategy.
As you start your transformation ask a few critical questions for investments:
1) Do you have the right team members – who can BE agile, not only DO agile?
2) Have you committed sufficient budget to invest in building key DevOps capabilities that can help in accelerating your organization?
3) Is your leadership committed to aligning resources and processes to ensure that flow can breakout?
4) Are your teams willing to be empowered and be held accountable? Is your leadership willing to de-centralize decision-making?
5) Does your leadership team recognize the value of a transformed organization and are they willing to dedicate top talent for a few months to drive organizational change?
The responses to these questions will give you an indication of what expectations need to be set with your team, leadership and stakeholders whom are all eagerly anticipating your transformation yield results.
As you start your agile transformation journey, ask the difficult questions, be honest about your organizational capabilities and those it lacks. Plan the transformation and communicate the transformation roadmap so that all stakeholders involved can a have realistic expectation of your agile journey. Otherwise, you may find yourself in jumping out from one boiling pot to different, “agile pot” and, again, not realize the heat is turning up. .
The Starting Problem Series – The Agile Resource Allocation Dilemma – Part 2
In the previous post, we outlined the Agile Resource Allocation Dilemma and recognized that this is a pervasive issue and a tough one to solve.
If you need some motivation to start solving for dedicated teams, here are some results that you could expect if you start agile teams without 100% dedicated allocation:
- Scheduling ceremonies – stand up, planning, review sessions, etc. become a nightmare due to conflicts in priorities and working on multiple initiatives, resulting in a lack of daily accountability of deliverables.
- Instead of teams working together every day and having opportunities to collaborate, they negotiate “how many core hours do we have a day and when?” This leads to uncertainty of delivery capability at the team level and more importantly task switching for resources that, as we know, causes waste in the system.
- The product owner and scrum master are often at odds with the functional managers whom still generally have delivery accountability and will often call the prioritization decisions. Given the other critical projects that need to be completed, additional task switching is inevitable.
- Sprint commitments mean nothing since team members with partial allocation do not consider the agile team as their “first team” and hence, struggle to establish and to own the team’s sprint goals. This commitment that individuals provide and then strive to meet, evaporates with partial allocation of resources leading to unmet sprint goals.
- Even for those team members whom are 100% dedicated to the team, it is often challenging to motivate them to commit to goals when other important team members are committed part-time to the cause and have other priorities. Missing sprint commitments becomes acceptable and a culture of commitment cannot find a foothold in the organization.
If you find yourself in this situation, here are some thoughts to consider:
- If you can get 100% allocation at the start of sprint – do it. This is absolutely the best course of action, so ask the “5 Whys” when someone tells you that “partial allocation is the best we can do.” By the time you get to the 5th Why, you will often find that the partial allocation mentality can be overcome.
- When you stand up agile teams, ensure that each team member can claim that their team is truly their “first team” – i.e. all work that is prioritized for a team member during transition is allocated via his/her first team. The functional managers need to request capacity from the product owner and scrum master of the agile team. In other words, if there is other critical project work, consider shifting those stories over to the team where the critical team member lives, prioritize it appropriately, and have the team commit to that work along with their other sprint commitments.
- Ensure that every person can claim that they are part of an agile team – i.e. they do 60% or more work for this team during transition. In this way, all team members will get familiar with operating within agile practices and they will most likely start demanding that all their work comes through the backlog and team commitments.
- Allow your product owner and scrum master to plan your initial sprints with capacity utilization of shared resources between 50% to 70% and gradually transition to 100% over 2 sprints. In this manner, you can treat the “other project work” as ad-hoc requests to be serviced with any remaining capacity.
- Determine a transition plan for achieving100% resource allocation, pick a date for getting there, and stick to it. The transition time will ease the pain of moving to the new allocation model and the deadline will provide some urgency to make sure you get there. This is time to be disciplined about the transition – don’t fake it!.
As a leader if you want to drive a “culture of commitment” in your organization, you have to demonstrate this commitment by your actions and allow agile teams to form that can make commitments. This is such a critical element for enabling your organization to create value at a sustainable pace. When you create dedicated teams, you significantly increase the team’s probability of success and hence, the results you expect from agile teams. When you have chosen to transform to an agile organization, begin with making this commitment – the commitment to fully allocated resources in the agile teams. The results will be exceptional!
Passed the Certified Scrum Professional Exam!
Happy to report that I took the Certified Scrum Profession (CSP) exam this morning and passed with flying colors! My biggest reason for working towards the exam was using it as a forcing function to do a whole lot of reading about a variety of agile subjects. Over the past 8-9 months, I read the following titles and added to my knowledge base using mind mapping software (I love iThoughtsHD on the iPad):
- Agile Software Development with Scrum – Ken Schwaber
- Agile Retrospectives: Making Teams Great – Esther Derby
- Succeeding with Agile: Software Development Using Scrum – Mike Cohn
- Agile Estimating and Planning – Mike Cohn
- Test Driven Development: By Example – Kent Beck
- Agile Product Management with Scrum – Mike Cohn
- Refactoring: Improving the Design of Existing Code – Martin Fowler
The Starting Problem Series – The Agile Resource Allocation Dilemma – Part 1
Congratulations! You have now convinced your management team to adopt agile. Everyone (or at least most) in your leadership team have extended their support toward this initiative. Everyone believes that this transformation will be excellent for your organization as 1) you are adopting agile 2) claim that your organization is challenging the status quo and 3) you will be able to do product delivery faster.
All transforming organizations and their respective leadership experience a tremendous amount of excitement during this phase. There is a desire to get 100% results and now the leadership team has to commit resources to agile teams to jump-start the transformation. At this “starting point” is when transforming organizations experience the challenges with making commitments.
Typically, prior to adopting agile, a software development and delivery organization would be organized around functional skills – Development, Quality Assurance, Project Management etc. This “tower” or “silo” organization makes sense in the waterfall world to “maximize” effectiveness of the delivery of the artifacts associated with that functional skill. In addition, team members work on multiple projects and tasks that are allocated to the resource by a project manager. This structure and process is very common across most pre-agile organizations.
In the new world, all these resources need to be part of agile teams – self organizing teams that produce 100% of the results based on sprint commitments made by its team members. The management team expects nothing less than this. However, the challenge facing leaders is that they often do not fully adopt the “dedicated team member” principle of agile and continue to allocate part time resources to the intended agile team. The most likely cause of continuing to split allocations of team members is that they still have a critical role or knowledge required to deliver other critical projects.
In the next posting, we will outline the impact of ignoring the dedicated team principle and some ideas for helping to transition to fully dedicated teams.
AgileTrailblazers sponsoring Agile DC 2013
AgileTrailblazers is proud to be one of the sponsors of Agile DC 2013. This conference is being held on Tuesday, October 8th from 7 AM – 5 PM at the Kellogg Conference Hotel at Gallaudet University in Washington, DC.
If you are attending, come by and meet Brian and Naeem at the morning coffee (on us!). We would love to meet you and talk with you about how AgileTrailblazers can help your organization achieve outstanding results with Continuous Business Value Delivery®.
If you haven’t signed up yet, go to the Agile DC site and make sure to be there for what promises to be a great event!
See you there!
The Big Lever
I have a new article published today with Scrum Alliance on why release orientation (vs. project orientation) is so important to being agile.
Team Design Patterns – Wrapping it up
Pulling all the ideas together from this article series, I want to leave you with a couple of key thoughts when you are trying to design your agile organization:
- When designing your next organizational structure, keep in mind that the target for your organization should be the Ideal Team Structure. The journey may take months or years, but you need to organize your teams to bring the opportunity to incrementally reach this target.
- Don’t avoid the inevitable disruption that a move from waterfall process to agile frameworks will bring. The impacts of the disruption won’t last for long and the benefits of doing business in an agile way will pay dividends quickly.
- Agile frameworks require thoughtful construction of an organization that maximizes delivery flow. Maximum delivery flow breaks out when the development teams are directly connected to the Business Intent Generators (BIG’s) and you don’t need multiple teams to turn intent into delivered solutions.
- These articles represent some agile team patterns. Your organization will most likely need one, many, or a hybrid of these patterns to be successful. If you have not had experience with an agile transformation and how to design your organization for this change, hire a solid enterprise agile coach to help you with this part of your transformation. You won’t regret it!
This completes this series on Team Design Patterns and I hope you found it useful and informative. Please post a comment to let know.
© 2012-2013 AgileTrailblazers, LLC – All Rights Reserved
Team Design Patterns – Feature teams with mixed-composite skills
This article is about the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skill teams.
Let’s assume that you still have an organizational issue of too much specialization of skills. With that assumption, it is difficult to jam-pack all skills, knowledge, and expertise into a 7 +/- 2 sized team to be able to transform every piece of business intent into a workable software solution. The idea behind mixed-composite skill teams is that you can create different mixtures of skills across many teams (each sized at 7 +/- 2) and design those teams so that their skill mix is a composite of skills that match the patterns of the business intent. Because you need the intent to be bite-sized (i.e., can be turned into “done” solutions in 2 weeks or less), it is very likely that any particular piece of intent will suggest changes to 5 or less platforms / components. So, let’s say that you design our teams in the following patterns:
- Teams 1 and 2 possess a mix of skills in components A, B, C, and D
- Team 3 possesses a mix of skills in components C, D, E, and F
- Team 4 possesses a mix of skills in components A, B, C, and F
- Team 5 possesses a mix of skills in components A, D, E, and F
- Team 6 possesses a mix of skills in components B, C, D, and E
Because the pattern of business intent suggesting software changes in components A, B, C and D is more common, you can allocate 2 teams (Teams 1 and 2) that align their skills to this pattern of intent. The skills in Teams 3 through 6 match less common, but still often occurring, patterns of business intent. So, as a final step in the story splitting and grooming process, you need to steer the final stories towards the teams that have the needed skills to turn the story into a delivered solution. This certainly adds a level of complexity to the Product Owner’s role – matching story intent to team skill mix. It also implies that you may need to broaden out the breadth of Business Intent Generators (BIG’s) that feed into this pool of mixed-composite skill teams to be able to reasonably utilize their capacity. For example, if BIG 1 (see picture in the Ideal Team Structure article) requires 3 teams worth of capacity to get its expected level of solutions delivered, it might be difficult to construct 3 teams with the right mixtures of components A through F and keep them all well utilized. However, if BIG’s 1, 2, and 3 were to share their teams, they would combine to require 6 teams worth of capacity to get their solutions delivered. You then have significantly more flexibility to build the right team skill mixes across 6 different teams to marry up with how the patterns of intent are generated from these 3 BIG’s.
One very key point in constructing mixed-composite skill teams is that it provides the real opportunity for knowledge sharing and movement towards development of generalizing specialists (multi-skilled team members). For example, a developer on Team 3 who starts out with specializing in component C knowledge could readily work with other developers on the team to pair program and learn components E and F. Once that developer is now knowledgeable in all 3 of these components, they could be moved to Team 1 and provide the ability for that team to cover any story that involved change to components A through F. With leadership permission to broadly spend on knowledge sharing, you will have many teams that could handle any business intent that came their way. Before you know it, this organizational structure has transformed into the Ideal Team Structure.
So, if you can figure out what your patterns of business intent look like and then can build teams that fit those patterns, you will be blazing a trail towards 100% feature teams by starting with mixed-composite skill teams.
In the next and last article in this series, I will wrap up my thoughts on feature and component teams.
© 2012-2013 AgileTrailblazers, LLC – All Rights Reserved
Team Design Patterns – Feature teams supported by component teams
In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.
Here is a picture of an example solution delivery organization with feature teams and components teams:
From a flow perspective, Business Intent Generators (BIG’s) create a product backlog for one or more feature teams. The feature teams are built with members whom have the skills and knowledge most aligned with building solutions that meets the business intent. Additionally, the feature teams are constructed to maximize their ability to build the solutions for that business intent before needing to reach out to other teams to develop other required portions of the overall solution. When the feature teams get too big to be truly agile, you can create component teams constructed from team members with skills and knowledge specialized around specific platforms and/or components. Reminder – when beginning your agile transition, this model only makes sense when you have too much specialization of skills to allow the ITS to break out.
When the feature teams need updates to platforms and/or components that live outside of their team, they create backlog items for the component team(s). The component team Product Owner works with the feature team Product Owners to prioritize backlog items coming from across potentially many feature teams. If you need to organize with component teams, it is best if each feature team only needs to interact with one component team that has all of the skills and knowledge of platforms and/or components not present in the feature team. In this design, there are two teams (i.e., one feature team and one component team) involved in delivering solutions to meet the business intent. If your architecture is very complex and specialization is very deep in the components of that architecture, you may need to have multiple component teams servicing each grouping of feature teams if all the component skill and knowledge cannot fit into one 7 +/- 2 component team. Whether you have one or more component teams for any feature team, it is most important to mix up the component specialization skills in each of the component teams so that team members can start working on cross-training and knowledge sharing across the various components and start the journey towards building an organization of generalizing specialists. It may be tempting to organize your component teams around singular components to minimize the disruption to current organization of platform/component specialists. This is probably the worst option for component teams as it does not provide any cross-training opportunities nor any path towards building an organization of generalizing specialists for the ITS. The organizational re-design may be unsettling to team members. However, it may be an important aspect of beginning your journey to agile solution delivery with a clear signal to your organization that business will now be done differently. If the reasons for the organizational decisions and change are clear and communicated well, the shock of the new organization will soon pass and the highest majority of the team will help get the company to the new way of operating.
In the next article, I will outline the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skills.
© 2012 AgileTrailblazers, LLC – All Rights Reserved