From the title of this post, it might seem that we are going to beat up on the ‘status reporting’ aspect. Let me clarify here, both are equally important and convey critical pieces of information to the audience.
What I want to highlight in this post is how inefficiencies are caused due to one replacing the other. In organizations using Agile, adapting to the changing landscape is a central tenet to its way of working. How people communicate is a significant factor in the success or failure of an organizations’ ability to adapt to change.
Before we explore how organizations struggle with effectively using the two ways to communicate, let’s first align on what they are.
Status reporting: The primary intent of this interaction is for one stakeholder to provide information to other stakeholders about the current state of progress. It is a one-way conversation with the information primarily flowing from the status update provider to the listener. There might be some interaction for clarification or instruction, but it is not built into the central idea of the interaction.
Inspect and Adapt: The primary purpose of this interaction is for the stakeholders to examine the progress towards the end goal, identify risks, acknowledge impediments and figure out actionable takeaways that will resolve or mitigate any challenges towards progress. Most Agile ceremonies share this primary intent and should be facilitated as such to achieve the aforementioned outcome.
What really happens: No matter how mature an organization is in its Agile journey, organizational factors such as psychological safety and human psychology influence how people contribute to the ceremonies. Let’s take a closer look at a couple of factors:
FOMO: Fear of Missing Out. When there are no efficient ways to know the latest status of work, people tend to gravitate towards asking for status-related information during Agile ceremonies. If the status is made transparent and highly visible to the stakeholders, it will greatly reduce the desire to discuss it during discussions that should really be inspect and adapt. In Agile organizations, the use of BVIRs (Big Visible Information Radiators) such as Scrum Boards and relevant Agile metrics can accomplish this. It is critical to make the BVIRs readily accessible and easier to consume to get better user adoption.
Perception and Recognition: Human behavior is often affected by how your actions will make you look. A status report allows a person to state what they have worked on so far and how it will make them look in the eyes of the audience for their progress. Inspect and adapt discussion makes people state the problems they are or could be facing and ask for help. It is a natural human tendency to try and not be the bearer of bad news. Especially in public forums, such as the Agile ceremonies. If people are getting enough recognition for their work and are made to feel safe for opening up and expressing concerns during the inspect and adapt discussions, the Agile ceremonies can become highly effective.
Tactically speaking, standups and scrum of scrums are typical examples of Agile ceremonies that should be heavily focused on inspect and adapt aspects. What ends up happening on most teams and programs is the ceremony turns into a status reporting session, leading most participants to not get true value out of the interaction.
If you would like to get some tactical advice on how to make these ceremonies more effective, please join us in a free webinar on November 3rd at 12pm EST, where I will discuss the topic in more detail with a fun story about chicken curry, draw the parallels and then do a deep dive into some effective techniques you can implement right now to improve the inspect and adapt aspect in your organization. Click here to register.
Metrics are vital to a team. They give us a starting point, just like choosing “my location” on your GPS. Then metrics tell us where we are headed. They help us know whether our team is winning at continuous improvement. They tell us how our journey is going, and where we might be off course.
The stability of metrics demonstrates that teams are predictable and can forecast future work. Many times, it is a combination of metrics that give us the real picture though.
One measure that can demonstrate a team’s stability is velocity. A team made up of dedicated members should have a stable velocity over time, which helps them better determine how much work to commit for a given sprint. So, measuring velocity over a number of sprints is a great Scrum metric. You might think that a rising velocity is good. However, a rising velocity along with rising escaped metrics tells us we haven’t reliably sped up at all. In fact, if escaped defects are rising, we need to fix something else in our process. We may need to slow back down. In contrast, a rising velocity and a decreasing or stable number of escaped defects would be a good team goal.
Another metric for a Scrum team is Committed vs Delivered %. Rather than just focusing on velocity, add a measure of Committed vs Delivered for velocity to see how your team is doing at being predictable. Teams that frequently have a low percentage of Committed to Delivered are committing to too much work in the sprint. If this is happening to your team, it is time to figure out why. Sometimes, we will know exactly what has impacted our metrics, while other times we may need to have a retrospective to discuss why. Escaped defects are important to consider, as a high percent Committed to Delivered is good, lots of rework is not.
While Velocity and Committed vs Delivered % are end-of-sprint metrics, throughout the sprint, a team’s burndown gives us a view into progress during the sprint. It’s important to look at a team’s burndown every day to assess whether the team is likely to complete all the work they committed to. Burn-down gives us the point-in-time view of the work to be completed within the sprint. If the remaining work is far above the ideal burndown line, we may need to have a conversation with the Product Owner about stories that won’t be completed. On the other hand, if the burndown is far below the ideal line, we may be able to bring another story into the sprint.
Some teams go a step further and measure Cycle Time for stories. Cycle Time starts when a team member starts work on the story and continues until the story is moved all the way to the team’s done column. Cycle time can help us determine if we are right-sizing our stories. For Scrum, stories are right-sized to just a couple of days of work or less. If Cycle Time for stories is extending well past a couple of days, you may need to try and break your work down into smaller pieces.
Using a combination of metrics and charts for a Scrum team can help the Scrum team spot problems and see if their experiments are working. These internal team metrics are just the start and give an even fuller picture when customer outcome metrics are added, but that is a topic for another post. Do not let your team meander along. Get them metrics to see where they are and where they are heading.
If you missed Philippa Fewell’s Meet Up where she speaks about how Agile 2came about – you are in luck, we have it here! Philippa shares with us how she and a group of 14 other Agilists reflected together over a period of 8 months to create a new set of values and principles called Agile 2. We invite you to listen, learn and enjoy her lively discussion!
According to Deutsche Bank CIO Frederic Veron, “enterprises that wish to reap the potentially rich rewards of getting IT and business line leaders to build software together in agile fashion must also embrace the DevOps model.”
Why is that? It’s simple: DevOps is necessary to scale Agile. DevOps practices are what enable an organization to rapidly deploy changes to many different parts of their product, across many products, on a frequent basis—with confidence.
That last part is key. Companies like Amazon, Google, and Netflix developed DevOps methods so that they could deploy frequently at a massive scale without worrying if they will break something. DevOps is, at its core, a risk management strategy. DevOps practices are what enable you to maintain a complex multi-product ecosystem and make sure that everything works. DevOps substitutes traditional risk management approaches with what the Agile 2 authors call real-time risk management.
You might think that all this is just for software product companies. But today, most organizations operate on a technology platform, and if you do, then DevOps applies. DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.
DevOps methods apply to any enterprise that creates and maintains products and services that are defined by digital artifacts.
That includes manufacturers, online commercial services, government agencies that use custom software to provide services to constituents, and pretty much any large commercial, non-profit, and public sector enterprise today.
As JetBlue and Breeze airlines founder David Neeleman said, “we’re a high-tech company that just happens to fly airplanes,” and Capital One Bank’s CIO Rob Alexander said, “We’re a founder-led, 20-year-old technology company.”
Most large businesses today are fundamentally technology companies that direct their efforts toward the markets in which they have expertise, assets, and customer relationships.
DevOps Is Necessary at Scale
Scaling frameworks such as SAFe and DA provide potentially useful patterns for organizing the work of lots of teams. However, DevOps is arguably more important than any framework, because without DevOps methods, scaling is not even possible, and many organizations (Google, Amazon, Netflix…) use DevOps methods at scale without a scaling framework.
If teams cannot deploy their changes without stepping on each other’s work, they will often be waiting or going no faster than the slowest team, and lots of teams will have a very difficult time managing their dependencies—no framework will remedy that if the technical methods for multi-product dependency management and on-demand deployment at scale are not in place. If you are not using DevOps methods, you cannot scale your use of Agile methods.
How Does Agile 2 View DevOps?
DevOps as it is practiced today is technical. When you automate things so that you can make frequent improvements to your production systems without worrying about a mistake, you are using DevOps. But DevOps is not a specific method. It is a philosophy that emerged over time. In practice, it is a broad set of techniques and approaches that reflect that common philosophy.
With the objective of not worrying in mind, you can derive a whole range of techniques to leverage tools that are available today: cloud services, elastic resources, and approaches that include horizontal scaling, monitoring, high-coverage automated tests, and gradual releases.
While DevOps and Agile seem to overlap, especially philosophically, DevOps techniques are highly technical, while the Agile community has not focused on technical methods for a very long time. Thus, DevOps fills a gap, and Agile 2 promotes the idea that Agile and DevOps go best together.
DevOps evangelist Gene Kim has summarized DevOps by his “Three Ways.”One can paraphrase those as follows:
Systems thinking: always consider the whole rather than just the part.
Use feedback loops to learn and refine one’s artifacts and processes over time.
Treat everything as an experiment that you learn from, and adjust accordingly.
The philosophical approaches are very powerful for the DevOps goal of delivering frequent changes with confidence, because (1) a systems view informs you on what might go wrong, (2) feedback loops in the form of tests and automated checks tell you if you hit the mark or are off, and (3) if you view every action as an experiment, then you are ready to adjust so that you then hit the mark. In other words, you have created a self-correcting system.
Agile 2 takes this further by focusing on the entire value creation flow, beginning with strategy and defining the kinds of leadership that are needed. Agile 2 promotes product design and product development as parallel and integrated activities, with feedback from real users and real-world outcomes wherever possible. This approach embeds Gene Kim’s three DevOps “ways” into the Agile 2 model, unifying Agile 2 and DevOps.
Recently, I read an article titled, “Why Distributed Software Development Teams Work Infinitely Better”, by Boris Kontsevoi.
It’s a bit hyperbolic to say that distributed teams work infinitely better, but it’s something that any software development team should consider now that we’ve all been distributed for at least a year.
I’ve worked on Agile teams for 10-15 years and thought that they implicitly required co-located teams. I also experienced the benefits of working side-by-side with (or at least close to) other team members as we hashed out problems on whiteboards and had adhoc architecture arguments.
But as Mr. Kontsevoi points out, Agile encourages face-to-face conversation, but not necessarily in the same physical space. The Principles behind the Agile Manifesto were written over 20 years ago, but they’re still very much relevant because they don’t prescribe exactly “how” to follow the principles. We can still have face-to-face conversations, but now they’re over video calls.
This brings me to a key point of the article -” dispersed teams outperform co-located teams and collaboration is key”. The Manifesto states that building projects around motivated individuals is a key Agile principle.
Translation: collaboration and motivated individuals are essential for a distributed team to be successful.
You cannot be passive on a team that requires everyone to surface questions and concerns early so that you can plan appropriately.
You cannot fade into the background on a distributed team, hoping that minimal effort is good enough.
If you’re leading a distributed team, you must encourage active participation by having regular, collaborative team meetings. If there are team members that find it difficult to speak above the “din” of group meetings, seek them out for 1:1 meetings (also encouraged by Mr. Kontsevoi).
Luckily, today’s tools are vastly improved for distributed teams. They allow people to post questions on channels where relevant team members can respond, sparking adhoc problem-solving sessions that can eventually lead to a video call.
Motivated individuals will always find a way to make a project succeed, whether they’re distributed, co-located, or somewhere in between. The days of tossing software development teams into a physical room to “work it out” are likely over. The new distributed paradigm is exciting and, yes, better – but the old principles still apply.
CC Pace’s Philippa Fewell and Agile 2 Academy have co-authored a white paper “Is Your Agile Journey Evolving?”. Here they discuss the evolution of Agile and help you identify if your organization’s Agile adoption has kept up. We would love to hear your thoughts on your Agile journey!
To learn more about Agile 2, visit the website here.
A look at Agile 2’s values and why we need both sides of the coin to create value.
While the values of the original Agile Manifesto have helped shift the way software is developed today, it is very much left to the interpretation of the individual applying them as to how it should be done. This interpretation can often be dogmatic to focus solely on the left, sometimes at the total exclusion of those on the right, even though it clearly states “That is, while there is value in the items on the right, we value the items on the left more”.
Agile 2 consists of six values and 43 principles. It comprises a deep and nuanced set of ideas, and all of its ideas are supported by the thoughts that led to them. In this article I am going to provide a view into Agile 2’s six values and why we chose the word ‘and’ instead of ‘over’. Agile 2 seeks a balance of both the left and the right, both are needed, and both are useful. Also, Agile 2 seeks to speak to a broader range of activities beyond only software, including product development in general, and in fact any collaborative human endeavor.
The Values of Agile 2
Let’s take a look at them one by one.
1. Thoughtfulness and Prescription.
Frameworks are good and useful. They often give us a place to start and help us to solidify an approach. But they should not be followed blindly without considering your own context – where are you and what can and can’t you do in the context of your organization. Many variables are at play to construct the perfect environment for a framework to succeed, including organizational structure, culture, compliance regulation, and leadership support to name a few. A practice that is best for one organization may not be the best or have a chance of succeeding in another. That is not to say that you can’t move towards an ideal, but it very often isn’t the place you can start.
This contextual variability is why thoughtfulness is essential when applying a framework, or any practice or methodology. However, there are cases when one should start with a well-defined practice and follow it precisely. For example, if one is replacing a component of a complex machine, such as a blade on a jet engine, following procedure is often essential for ensuring that it is done right. Lives and safety might depend on following the procedure rather than improvising.
Still, judgment is sometimes required. Surgeons often have procedures for specific types of operations, but they need to be able to improvise, using their own judgment, when things do not proceed as expected; their experience and judgment are key, and the patient’s life might depend on it.
There is a place for prescription; and there is a place for thoughtfulness. Knowing the right balance is a matter of context.
2. Outcomes and Outputs
In the course of product development, outputs are the things that get produced by the development teams. These are usually design artifacts: digital files that define the product and its fabrication (hardware) or deployment (software).
Outputs are important – they help us measure our progress using metrics such as the team’s throughput, number of defects, quality of the software etc. These are mainly what you might call activity-based measures. But ultimately, we are building products or creating a service for our customers using Agile to achieve some business outcome. Sure, the customer will care about the quality, no one wants a product that is not stable, and the organization may not achieve its revenue target or market share if the product is not released on time. But the product also needs to be what the customer wants and will use. It must be the right product and someone or some group needs to be accountable for directing that vision to achieve the desired outcome, which is the true measure of success for the organization.
So, outputs matter: they are essential elements of any process; but they are not the end goal. The end goal is the outcome.
3. Individuals and Teams
We often hear there is no ‘I’ in ‘Team’ and much of what is written about Agile is written regarding the practices of the team. Teams are necessary to accomplish much of what we do, as no one person has the knowledge or capacity. But Agile often advocates for the team’s preference over the preference of the individual, be it with team norms, communication style, and even the team environment. This can be to the detriment of the individual, which can then cascade into the detriment of the team reaching its goals.
Balance is needed so as not to stifle creativity or alienate team members simply because they do not think, learn, or process information in the same way. It is necessary for teams to have norms but sometimes allowing someone to operate outside of the majority’s norm is needed too to accomplish the team’s goal.
4. Business Understanding and Technical Understanding
We often hear that business is the driver, and that technology is the enabler, that the business is responsible for the “what” and that IT is responsible for the “how”. This thinking has led to many structures where development teams are led by product managers who have a great understanding of their domain but very little understanding of how it will be implemented and vice versa. But knowledge of both is necessary to make optimal decisions.
Technical decisions have financial and future business impact, and business decisions have financial and future architectural impact. Not every person can have a deep understanding of both, but they should not entirely shift the accountability of understanding to someone else. Instead, they should seek to understand as much as possible and collaborate closely.
5. Individual Empowerment and Good Leadership
Self-organizing teams is one of the first things people often talk about when discussing Agile. Two of the principles behind the original Agile Manifesto state:
“Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done” and
“The best architectures, requirements, and designs emerge from self-organizing teams.”
These are often translated into “leave the teams alone and don’t tell them what to do”. Yet not all teams are ready for that level of autonomy and authority.
Empowering teams, or individuals for that matter, is a great motivator. It can bring about better outcomes, and it can help to build future leaders within the organization. But to empower people without some level of supportive leadership and assessment is to set them adrift. Borrowing from a talk by former Captain David Marquet, teams need to have clarity of purpose to set direction and competency and the capability and skills necessary to get the job done . Good leadership will assess the level of oversight and direction that the team needs and help them navigate while teaching them how to make good decisions on their own.
6. Adaptability and Planning
One of the original values of the Agile Manifesto contains the phrase “…responding to change over following a plan”. I do not think anyone would disagree that planning can be useful, or that if there were a significant change that would cause the goal to not be achieved then adapting the plan would not be a good idea. The point is that both the act of planning and the ability to adapt that plan are valuable.
The planning in and of itself helps us to think through the variables that would have us choose one option, course of action, timeline, etc. over another. It helps us think through the constraints we must work under and the risks we face if we come up against them. Keeping these things in mind with respect to what is occurring while executing the plan gives us useful information, we can use to adapt the plan for a better outcome.
Both sides of the coin, heads and tails, are necessary to create value. Agile 2 believes that both sets of values are necessary to achieve agility. Balance is needed and consideration for the context of your situation when applying practices that might favor one over the other. I do not believe the Agile Manifesto meant to infer only one side of the coin either, and that the word ‘over’ has led to misinterpretation and rigidity on how to apply it. I could be wrong in my view and understanding also. Therefore Agile 2 has provided interpretation and insight as to how the values were derived, so as not to be misinterpreted. There is a lot of thought and experience behind them from the original authors. However, we expect Agile 2 to evolve and develop with input from the community. We hope that you take some time to review Agile 2 and add to the ideas and content that comprise it.
In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of knowledge that a Product Owner’s effectiveness is measured on. We looked at how various aspects of empathy influence a Product Owner’s ability to connect with the team, client and organization in our second post. In our third and final post in this series, we are going to look at the impact that psychological safety has on a Product Owner’s success.
Psychological Safety: Psychological safety is a state of mind and a cultural aspect that is created and fostered by someone or something other than the subject themselves. When people in the organization are afraid to make difficult choices and shy away from having tough conversations, it is generally due to a lack of psychological safety. Various factors contribute to how safe people feel psychologically in an organization. Empathy, as discussed above, at all levels plays a big role in this. If the culture, in general, is more empathetic, there will be a higher level of psychological safety. However, it is not the only factor. Let’s dig a little deeper on this factor and see how PO’s success is tied to psychological safety for themselves and the teams they are working with.
Psychological Safety for Teams: In the case of teams, it is usually the leaders that are responsible for ensuring that team members feel psychologically safe to work in challenging situations with often unpredictable outcomes. Agile requires teams to be flexible and collaborative in their approach to address the ‘just-in-time’ nature of work. Innovation, exploration, and taking risks is a necessity to succeed in such an environment. This comes with the possibility of teams running into occasional failures that should be treated as learning opportunities. But, if the organizational culture is not forgiving of failures, it leads to teams not feeling safe enough to take the risks and challenges they may need to, to optimize value delivery. Leaders should actively address the topic of psychological safety and ensure that they foster a culture that encourages innovation and taking calculated risks.
Psychological Safety for the Product Owner: The Product Owner is in a unique position having a tremendous influence on a team’s psychological safety, but in turn, are equally or proportionally affected by the psychological safety afforded to them by their leadership. A Product Owner who is well engaged with the team will need to make decisions regarding priority, scope, and timelines. An empowered Product Owner will be able to make such decisions with appropriate communication, keeping the team working at a sustainable pace. However, we often see organizations where such pivots must go through multiple levels of approvals, often surrounded by process constraints and red tape. This causes the organization to see change as undesirable and anyone bringing the change is viewed as the bearer of bad news.
Having leadership that welcomes change, is key to providing psychological safety to the Product Owner and the team. It is not sufficient for leadership to merely say that they support and welcome change. They need to look at systemic and cultural aspects of the organization that might be working against this mindset and actively work to realign them to an Agile way of working. It may not be the norm in some organizations to have leadership unsupportive of change, but a delay in the ability to pivot can lead to periods of unsustainable workload on the team while the Product Owner is negotiating upwards. To truly support psychological safety, allowing for making difficult choices and having tough conversations, organizations need to embrace decentralization decision making and empower the Product Owner and teams as much as possible.
I hope you enjoyed this series. Throughout these three posts, we explored various factors that impact the ability of a Product Owner to work effectively in their role and serve the purpose they are meant to. They must be empowered with knowledge of not just the business domain, but also the delivery and process knowledge to successfully operate in the organizational context. Empathy at different levels of the organization and towards the customer, whether they are internal or external, is crucial to move the product in the right direction. Psychological safety is often an unmeasurable and underlying factor that should be proactively managed by leadership and ingrained in the culture and processes of the organization to truly empower their Product Owners.
As a final thought, if you’ve enjoyed this series or have additional questions on how to truly empower your Product Owners, join me for a FREE webinar on Product Owner Empowerment. We have a few seats available (on a first-come basis) and invite you to register today.
In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of ‘Knowledge’ that affect a Product Owner’s effectiveness. This post is going to take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed.
Empathy: Assuming positive intent, empathy is something that comes naturally to a person. However, environmental factors can influence a person’s ability to relate or connect with another person or team. Let’s explore some aspects of empathy and how they may impact a Product Owner’s success.
Empathy towards the team(s): To facilitate an empathetic relationship between a Product Owner and the team, the PO must be able to meet the team where they are (literally and figuratively). Getting to know the team members and building a rapport requires the Product Owner to extensively interact with the team and proactively work to build such relationships. Organizations should facilitate this by making sure Product Owners are physically located where the team is and is empowered to not only represent the team to the business but also play the role of protector from external interruptions, so that team can function effectively. As alluded to above, having a good understanding of what it takes to deliver, helps tremendously with the ability to place themselves in the team’s shoes and see things from their perspective.
Empathy towards the customer(s): It is easy to assume that a Product Owner acting on behalf of the business will automatically have empathy and an understanding of their needs to adequately represent their business interests. However, organizational culture can sometimes influence how a Product Owner prioritizes work. If it is only the sponsors directing the team’s scope and prioritization, a critical element of customer input is missed. Product Owners should place sufficient emphasis on obtaining customer opinion and feedback to inform the direction of product development.
Empathy in the Organization: This factor relates to the organizational culture. As companies embrace Agile and expect its benefits to be equally realized, more emphasis on the desire to be lean begins to form. While being lean is a goal every organization should have, it is important to understand what kind of impact a lean organization has on individual teams or team members. A systemic push to be lean, in combination with less than optimal Agile maturity and the presence of antipatterns, can lead to teams being held against unsustainable delivery expectations. This problem is more common than you would think. Most organizations are going through some level of Agile transformation, but leadership expectations of benefits realization are always a few steps ahead of where the organization truly is on the Agile journey. Having the right set of expectations and the empathy necessary to reset them based on continuous learning and feedback is needed at an organizational level.
Check back next week to see how a Product Owner’s success is tied to psychological safety for themselves and the teams they are working with.
If you are a Product Owner or your Agile team struggles with this role, you won’t want to miss our upcoming webinar on Product Owner Empowerment. This webinar will be held on December 15th and you can register today here! Space is limited and on a first-come basis.
The Product Owner plays a crucial role in the success of a team and subsequently the organization. Most organizations consider the Product Owner to be a person with sufficient business knowledge such that they can communicate the business needs to the teams for implementation. While this is an important qualifier for a Product Owner, other factors must be present to have a truly empowered Product Owner.
The following 3 factors have the biggest impact on a Product Owner’s ability to succeed:
These factors are not just applicable to the Product Owner, but also the surrounding environment. This includes the organization, processes, culture, teams, the product itself, stakeholders, and customers. Let us dig a little deeper.
In this post, we are going to focus on the first influencer: Knowledge. Next week, we’ll take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed, and we’ll round out the series with defining Psychological Safety and looking at the effect it has on a Product Owner.
Knowledge: The knowledge aspect is the most obvious and widely analyzed and assessed factor to evaluate the effectiveness of a Product Owner. However, there are several dimensions of knowledge that are required.
Domain Knowledge: This dimension doesn’t need explaining and is probably the most obvious one of all. The Product Owner must have a good understanding of the domain they are working in, to effectively lead product development. While it may seem comfortable to assume that industry-wide it is common practice to have Product Owners with sufficient domain knowledge, some Agile antipatterns have led to the emergence of roles such as proxy Product Owner, or technical Product Owner. The primary culprit for organizations gravitating to this antipattern is a lack of understanding of the Product Owner’s role. Organizations assume that as long as there is a communication path to transfer the business needs to the teams, it is ok to have layers between the customer and the team. This creates dysfunction in Agile teams that are supposed to collaborate with the Product Owner in discovering and delivering value, but don’t have an empowered Product Owner who can make decisions and pivot when needed effectively.
Process Knowledge: When it comes to a PO having knowledge and understanding of the Agile approach, best practices, and antipatterns usually takes a back seat. To clarify, we are not talking about just having your PO take a 2-day certification class and call it a day. Yes, it is necessary to have formal learning as part of role development, but, the learning should not remain at this minimal level. An effective Product Owner should have lived the process, learned from the challenges, successes, and failures, so they understand what it takes to deliver the product they are helping build
Knowledge of PO role across in the organization: We talked about knowledge that a PO should have, but, to have a truly empowered Product Owner, an organization needs to know what to do with such a role. As mentioned before, a Product Owner role is different from a mere subject matter expert. To empower a Product Owner to make decisions, the organizational stakeholders need to understand how the Product Owner role works in an Agile context. Product Owners are not only the primary source of information on business needs for the team but are also one of the key roles influencing the pace of value delivery.
If the organization doesn’t understand what it takes for an Agile team to receive business needs Just-in-Time, iterate on requirements, let design emerge, deliver value and allow for slack time and innovation, It will make a Product Owner’s job quite difficult if they are still held to traditional expectations from leadership. These expectations may include providing inflexible delivery commitments, obtaining buy-in from a myriad of stakeholders before any scope changes are made, or worst of all, ensuring maximized utilization from the team. The organization’s stakeholders must be trained and knowledgeable about the basics of Agile if they are new to this way of working. Additionally, leadership must know the common pitfalls, assumptions, and antipatterns that organizations fall into and actively work to avoid or mitigate them.
If you are a Product Owner or your Agile team struggles with this role, join me for a free webinar on Product Owner Empowerment. This webinar will be held on December 12th and you can register here! Space is limited and on a first-come basis.
Agile 2 is here!
I was fortunate to be included in a group of exceptional Agile leaders and practitioners, led by Clifford Berg, to retrospect on Agile and improve upon what it has become over the last 20 years. Each of us began by citing issues and problems we have encountered over the years, drawing on our unique experiences. Not all of us experienced the same issues, but it was eye opening to discover what others came up with because of the diversity of the group both in practice and expertise.
We then discussed why we felt the problems occurred and what could be done to change them. This led us to revisiting the values and principles of the Agile Manifesto and many of the frameworks we use today. While I am vested in many of these, having become certified in them myself and trained others on them as well, I have seen where lack of clarity or difference of interpretation, as well as too much emphasis placed on prescription, leads to less than successful outcomes.
It is this clarity and thoughtfulness that Agile 2 seeks to deliver. It is a set of values and principles based on common problems that we believe will resonate with you, the Agile practitioner. My colleagues and I are proud of Agile 2 and the potential impact we believe it can have on the current state of Agile. Have we gotten it all right? Undoubtedly there is room for debate. Have we missed some valuable principles? Perhaps. And that is why we want Agile 2 to be open to ideas from the community, and there will be an Agile 2 version 1.1. We respect and welcome your input and ideas. We want Agile 2 to be constantly improving on what it is today so that it stays relevant. There will be Agile 2 community forums, and to begin that, there is a LinkedIn group. A book is on the way. The Agile 2 website is at https://agile2.net. Check it out!
CC Pace is ready for AgileDC! We are looking forward to hearing some great speakers and meeting with other Agile practitioners in the DC area. As a sponsor this year, we’re excited to be a part of what is always a great local event for the Agile community. Don’t forget to stop by our booth to meet our team and enter our drawing for your chance to win a $500 Amazon Gift Card!
See you at AgileDC!
CC Pace spent an informative day at the Center for Innovation Technology (CIT) event in Herndon, VA: Lean Agile DC. Jason Velentino (Director, Digital Reliability Engineering at Capital One) kicked off the conference with a great presentation on DevOps and his journey through incorporating cloud and a DevOps culture at such a large organization. It is rewarding for CC Pace to have been a part of the Agile adoption at Capital One, providing Agile Coaching and Training over the past five years and to see the evolution of Agile, which Capital One has made part of their everyday culture.
Another great presentation and discussion on Agile Engineering was lead by Jose Mingorance, and Carlos Rojas of Fannie Mae. They have pulled together a lot of ideas from Agile leaders to provide Fannie Mae with an exciting assessment and plan to drive business value throughout their organization through advancing Agile engineering practices. It was interesting to see their plans and the excitement surrounding this initiative.
Finally, Dean Chanter, also from Capital One, lead a great discussion on Joshua Kerievsky’s Modern Agile principles. Dean spoke about his journey towards ‘modern Agile’ at Capital One and how those principles are at the cornerstone of their advancement in their Agile transformation as an organization. As Capital One continues their trajectory into being Agile leaders in the Financial Services market, this will be an interesting case study to keep an eye on! We look forward to next year and seeing how everyone has progressed.
A long while ago, the Boston Consulting Group (BCG) pushed its limited and ill informed conception of Lean by focussing on waste elimination. It defined what most of us believe Lean to be to this day.
Six Sigma, with relatively good mathematical science – but not perfect according to Donald Wheeler – jumped on the bandwagon of certifications with its famous – and no less dogmatic & command and control – belt structure. Although Six Sigma always quotes chapters and verses from the statistical work of the likes of Donald Wheeler, we never heard the likes of Wheeler endorse ‘Sick Stigma’ (a term borrowed from Dave Snowden) ! (Having read all of Wheeler books, I never saw a reference to Six Sigma anywhere)
A recent study from QualPro, a consulting firm that advocates an alternative quality process, points out that 53 of 58 large companies that use Six Sigma have trailed the S&P 500 ever since they implemented it. As if on cue, once-mighty proponents of the program have begun to scale back their involvement, if not abandon it outright. Two of the most recent dropouts: 3M and Home Depot. In fact, Robert Nardelli, the former CEO of Home Depot, was forced out in part because his Six Sigma program was blamed for plummeting customer satisfaction and employee morale. At 3M, management is rolling back many Six Sigma initiatives: The program, it decided, was not compatible with the spirit of innovation that had once made 3M great. Invention is an inherently risky, wasteful and chaotic process—exactly the sort of stuff Six Sigma seeks to eliminate
Coming back to software development, those 7 wastes were the focus of the earlier book by Mary and Tom Poppendieck, where both merely transposed the 7 wastes as it were to software development. Later books proved to be better aligned with the essence of value creation, which is the foundation of Lean.
The essence of Lean, as depicted by David Anderson’s lean decision filter, is where we should stand : a) Value trumps flow, b) Flow trumps waste elimination, c) Waste elimination trumps economies of scale.
Waste elimination is a distant third focus. But neither BCG nor Six Sigma truly understood the spirit of Lean.
Lean Kanban University’s teachings focus on Value first where the flow of work is visually illustrated with the dominant knowledge activities driving product development. Waste is of course addressed in a system’s thinking approach inspired from the scientific work of Goldratt and Demings.
Daniel Doiron is an Accredited Kanban Trainer (AKT) who works closely with CC Pace to deliver Kanban training and coaching to our clients.
“Once I started looking around behind the port frames, I figured I could just….”
And so began a summer of endless sailboat projects and no sailing. One project lead to the start of another without resolving the first. What does this possibly have to do with software development and Agile techniques?
My old man and I own and are restoring an older sailboat. He is also in the IT profession, and is steeped in classic waterfall development methodology. After another frustrating day of talking past each other, he asked how I felt things could be handled differently in our boat projects.
“Stop starting and start finishing!”
It is the key mindset for Agile. Take a small task that provides value, focus on it, and get it done. It eliminates distraction and gives the user something usable quickly.
Applying this mindset outside of software may not be intuitive, but can pay dividends quickly. On the boat, we cleared space on the bulkhead, grabbed a stack of post-its and planned through the next project, rewiring the boat. The discussion started with the goal of the project. “We’re just to tear everything out and rewire everything.” Talk about ignoring non-breaking changes! I suggested that we focus on always having a working product – a sail-able boat – and break the project into smaller tasks that can be worked from start to finish in short, manageable pieces of time.
Approaching the project from that angle, we quickly developed a list of sub tasks, prioritized them, and put them up on our make-shift Kanban board. This was planning was so intuitive and rewarding on its own that we did the same for other projects we want to tackle before April.
So stop starting, start finishing, and start providing value quicker for your stakeholders.
Outside of my work at the MSRB for CC Pace, I enjoy working with community organizations in Fairfax County. After eight years of running the Jefferson Manor Civic Association, I was named Chairman of the Lee District Assoc. of Civic Orgs (LDACO). This is an organization focused on improving communications between residents in the Lee District section of Fairfax, and the elected officials and staff of the county. I have been involved with the board of directors for several years, and was bursting at the seams with ideas on how to build on the foundation I had inherited.
The nearly unlimited options quickly brought about a familiar end result – paralysis. Ideas ranged from simple house-keeping to epic public festivals. It was, to be honest, complete chaos.
Thankfully, at the time I was working on my understanding of Agile techniques and how they applied to my work situation. A key source for this was ‘The Nature of Software Development” by Ron Jeffries. As the pages flew by, the point of always prioritizing value became clear. How could this perspective be focused on running an advocacy group for civic associations? The clouds parted and the way forward became clear.
Prioritize by what would provide immediate value to the organization and its members. Again referring to Jeffries, I used the “Five Card Method” to determine what our first ‘epics’ to tackle would be. The idea is pick three to five big ticket items that will provide immediate value, and focus on breaking those down into manageable pieces.
How do we determine what our members find valuable? Ask them. A review of LDACO’s contact list showed that it was incomplete and in some cases, outdated. We had no social media outreach, either. Improved, direct communication became epic #1.
Talking with leaders in other communities, as well as long standing members of LDACO, I learned that folks needed a longer lead time to plan on attending our meetings. Epic #2 was to provide a calendar of events with at least 90 days out.
Lastly, LDACO learned that our members wanted a district and county-wide focus for meetings and speakers. While having a very narrow topic may provide value for a single community, it did not translate to the diverse group as a whole. Epic #3 was to aim for big, broad topics with speakers who were involved in the decisions that impacted the largest number of communities.
These became the main focus of LDACO’s work for the past year. These were broken down into smaller, achievable pieces, then worked on and completed. In the past year, we have grown our communication list, begun to grow on social media, and increased our attendance and membership through meetings with important stakeholders. All because we kept the focus on what provided value for our customers.
Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?
Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all. So what does this have to do with being successful at Agile?
When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.
When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.
In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.
So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?
Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.
If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.
I’m just returning to work after Spring Break in Cancun. I’ve met some lovely people while enjoying the sunshine. As I chatted with those beside me at the beach and alongside the pool, two common questions are asked: What is your name? and What do you do for a living? The answer to the first question is easy, but the answer to the second question is much longer. Why? Because I can’t just stop with “I’m a trainer”. I enjoy talking about Agile and Scrum, and explaining the basic framework. I enjoy sharing with others how they can apply what I teach to just about anything. I enjoy sharing Agile stories because Agile works, and I like talking about how companies can adopt an Agile mindset.
When I start talking to someone about Agile, I begin by explaining first how past processes have fallen short. The trials and tribulations of a 1 or 2 year project plan, managing risk, reaching or missing milestones, and change requests to re-baseline the plan for any number of reasons come to mind. All with a real concern of delivering something that misses the mark in “delighting the customer”. Waterfall projects often have cost overruns, extended delivery dates, and a plethora of change requests that aren’t discovered until near the end of the project during User Acceptance Testing (UAT). For these reasons, Waterfall just doesn’t feel like the best choice to deliver software anymore.
I then move on to talk about why I, and so many others, choose Agile processes to build software today. So here is a little of what I talk about:
Continuous engagement with the customer and other stakeholders is key
Seeing progress through continuous delivery enables better feedback
Reduced risk and waste, which can save money and heartache
Adapting to change quickly, which allows for the customer to respond to market changes
Better quality deliveries by testing early and often
It isn’t magic, and it isn’t necessarily an easy transition to make. To become a truly Agile organization takes a true shift in how we and everyone else in our organization thinks about how work is performed both internally, and externally with our customers.
Yes, I am a bit of an evangelist. Sometimes I want to shout from rooftops “people get it together, follow Agile principles”, “walk the talk”, “quit being stuck in the past”. Our world is evolving every day. To keep pace with our competitors, we need to evolve too. Agile is an umbrella term for a number of methodologies including Kanban and Scrum. Today we find that Agile isn’t just for software anymore. The principles and methods can be followed just about anywhere to greatly improve our ability to deliver just about anything. That’s why I’m not just a trainer, but a believer.
When our yacht club saw membership dropping and was looking for a change, I called our Chairmen of the Board and suggested… a Kanban board.
Lucky for me, our Chairmen works in software for a well know online travel site. He knew just what I was talking about. After a short discussion, we decided to introduce the ideas of Scrum to the board. At our next Board of Directors (BoD) meeting I turned up, white board and 3 x 5 cards in hand.
Together we introduced the BoD to the idea of using a Scrum board to track our work. We started by brainstorming ideas in two key categories supporting the club’s 2015 goal of Membership retention and growth. Our two categories are membership activities and building improvements. After creating quite a backlog for the club, we discussed priority, and arrived at a commitment to working on a subset of the backlog for the upcoming sprint. Our sprint cycle was easy to determine as there are two meetings a month at the club, providing approximately 2 weeks in between each meeting. Board members signed up for stories listed in the backlog to get us off and running. At our general membership meeting, the visual board with our sprint and “product” backlog were introduced to the club.
Being “Agile” is a way of thinking. Core ideas like transparency, prioritizing, and collaboration can be incorporated into our everyday lives. I often suggest using a visual board for household chores when I’m doing training. No more nagging your partner, or kids. Just keep a board with 3×5 cards or post-its to identify upcoming work. Identify priority, acceptance criteria, and limit your work in progress by identifying a sprint length (one – two weeks work well). This helps to keep from feeling overwhelmed. Everyone is happier knowing what is expected. I’ve tried this at home with good success which is what led me to suggesting this for our club.
In taking these same principles and applying them to our club, we’re able to benefit from being Agile. The club members are our customers. They get visibility and input into the work being done. Members can make suggestions for new work, and volunteer to help. The club’s budget helps identify what can be afforded, and expected ROI helps us prioritize. Our initial work is underway, and I look forward to seeing our long-term projects lead us to sustaining and even growing our membership.
A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.
Here are 10 tips to keep in mind when helping teams in their transition:
Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size. And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.
If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points. It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.
Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it. Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.
Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself. It takes me a week. Assuming we’re taking the same route, and driving the same speeds, why is there a difference? It turns out that my friend can drive 12-13 hours a day with minimal stops. Whereas I start falling asleep after 2-3 hours and have to stop frequently. So it takes me longer (duration) to do the same amount of work (effort).
Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months. Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days. Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.
For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”. What others often hear is “it will take someone a week to do this”. I’m talking about effort; others are hearing duration.
The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours. But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.
Don’t define story points in duration-units and expect it to correlate to effort.
Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate. Use commitment based-planning and have them track their story throughput rather than points or hours. As they become more comfortable with this, stories will begin to creep smaller and smaller naturally. Check out more about the #NoEstimates movement.
Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it. Opt for shorter iteration lengths, as this will offer more opportunities to practice.
If teams are thrashing, there may be too many changes happening at once for them to absorb. We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.
Focus efforts on improving the ability to create vertical slices of value.
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating. Strive for small stories using story-splitting techniques. Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback. Smaller stories also improve the flow of work.
As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other. A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration. Mature teams will often have stories that take around one day, and all their stories are of similar size.
Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.
And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work. Forget the “if you challenge them, they will rise to the occasion” call to arms. After a certain point, that’s just a bunch of malarkey.
As my grandma used to say, “You can’t get blood from a turnip”.
As I mentioned in the introductory post in this series, an issue I frequently see with underperforming Agile teams is that work always spills over from one iteration into the next. Nothing ever seems to finish, and the project feels like a waterfall project that’s adopted a few Agile ceremonies. Without completed tasks at iteration planning meetings (IPMs), there’s nothing to demo, and the feedback loop that’s absolutely fundamental to any Agile methodology is interrupted. Rather than actual product feedback, IPMs become status meetings.
In this post, let’s look at how a Product Owner can help ensure that tasks can be completed within an iteration. As a developer myself, I’m focusing on the things that make life easier for the development team. Of course, there’s a lot more to being a good Product Owner, and I encourage you to consider taking a Scrum Product Owner training class (CC Pace offers an excellent one).
First and foremost, be willing to compromise and prioritize. An anti-pattern I observe on some underperforming teams is a Product Owner who’s asked to prioritize stories and replies, “Everything is important. I need everything.” I advise such teams that when you ask for all or nothing, you will never get all; you will always get nothing. So don’t ask for “all or nothing”, which is what a Product Owner is saying when they say everything has a high priority.
As a Product Owner, understand two serious implications of saying that every task has a high priority.
You are saying that everything has an equal priority. In other words, to the developer team, saying that everything has a high priority is indistinguishable from saying that everything has medium or indeed low priority. The point of priority isn’t to motivate or scare the developers, it’s to allow them to choose between tasks when time is pressing. You’re basically leaving the choice up to the developer team, which is probably not what you had in mind.
You’re really delegating your job to the developer team, and that isn’t fair. You’re the Product Owner for a reason: the ultimate success of the product depends on you, and you need to make some hard choices to ensure success. You know which bits of the system have the most business value. The developers signed on to deliver functionality, not to make decisions about business value. That’s your responsibility, and it’s one of the most important responsibilities on the entire team.
The consequence of “everything has a high priority” is that the developers have no way to break epic stories down into smaller stories that fit within an iteration. Everything ends up as an epic, and the developer team tends to focus on one epic after another, attempting to deliver complete epics before moving on to the next. It’s almost certain that no epic can be completed in one 2-week iteration, and so work keeps on spilling over to the next iteration and the next and the next.
Second, work with the developer team to find out how much of each story can be delivered in an iteration. Keep in mind that “delivered” means that you should be able to observe and participate in a demo of the story at the end of the iteration. Not a “prototype”, but working software that you can observe. Encourage the developers to suggest reduced functionality that would allow the story to fit in an iteration. For example, how about dealing only with “happy path” scenarios – no errors, no exceptions? Deal with those edge cases in a later iteration. At all costs, move towards a scenario where fully functional (that is, actually working) software is favored over fully featured software. Show the team that you’re willing to work with the evolutionary and incremental approach that Agile demands.
Third, be wary of stories that are all about technical infrastructure rather than business value. Sure, the development team very often need to attend to purely technical issues, but ask how each such story adds business value. You are entitled to a response that convinces you of the business need to spend time on the infrastructure stories.
At the end of a successful IPM, you as the Product Owner should have:
Seen some working software – remember, fully functional but perhaps not fully featured
Offered the developer team your feedback on what you saw
Worked with the developer team to have another set of stories, each of which is deliverable within one iteration
Prioritized those stories into High, Medium, and Low buckets, with the mutual understanding that nobody will work on a medium story if there are high stories remaining, and nobody will work on low stories if there are medium stories remaining
A clear understanding of why any technical infrastructure stories are required, and what business problem will be addressed by such stories
Finally, make yourself available for quick decisions during the iteration. No plan survives its first encounter with reality. There will always be questions and problems the developers need to talk to you about. Be available to talk to them, face to face, or with an interactive medium like instant messaging or video chat. Be prepared to make decisions…
Developer: “Sorry, I know we said we could get this story done this iteration, but blahblah happened and…”
You: “OK, how much can you get done?”
Developer: “We would have to leave out the blahblah.”
You: “Fine, go ahead.” (Or, “No, I need that, what else can we defer?”)
Next post, I’ll talk about what developers should concentrate on to make sure some functionality is delivered in each iteration.
“MAKE IT SO”
If you’re a fan of “Star Trek: The Next Generation”, then you’re familiar with this phrase. I can see it now….Captain Jean-Luc Picard standing on the bridge of the U.S.S. Enterprise, facing a situation requiring action. He asks for options, listens to recommendations, and conveys a decision to move forward by telling the crew to Make-It-So. His decision communicates “what” needs to happen, but he trusts the crew to figure out “how”. This is the essence of a Make-It-So (MIS) culture, a pervasive attitude of leadership throughout an organization, resulting in an environment that supports growth, encourages exploration, demands excellence, and emphasizes accountability.
In an MIS culture, everyone has a place in the fabric of the organization….they are valued and valuable, and they know it. Everyone has an important part to play….and they are expected to play it. People are skilled and competent….and because they are, they’re confident. People are empowered, they are “granted permission” to contribute ideas, to make decisions, to take risks…to “make it so”.
Ten characteristics I’ve experienced in an MIS culture include:
“When nothing is certain, everything is possible.” – Margaret Drabble
We are informed by, but not tied to, what was. We are grounded in the here and now, yet remain open to what could be. We don’t drag ourselves down with visions of doom, but maintain a sense of hope and optimism.
“Concentrate all your thoughts upon the work at hand. The sun’s rays do not burn until brought to a focus.” – Alexander Graham Bell.
When vision and purpose are visible and shared, it provides us context. We know the direction and why, so we can act and make decisions accordingly.
“No man is an island, entire of itself; every man is a piece of the continent, a part of the main.” – John Donne
We know it “takes a village” and we can’t do it alone. Success depends on the combined strengths and contributions of everyone.
“The key is to get to know people and trust them to be who they are. Instead, we trust people to be who we want them to be, and when they’re not, we cry.” – David Duchovny
We trust in each other’s positive intent, and believe everyone does the right thing at the right time with the information they have. We act, make decisions, and move on. While we reflect on what we learn from experience, we don’t undermine confidence by second guessing ourselves or others.
“It’s not what we profess, but what we practice that gives us integrity.” – Sir Francis Bacon
We seek to know ourselves, to be ourselves, to be proud of ourselves, our organization, our place in it, and our contributions. Our actions are congruent with who we are, our beliefs, our passions, and our strengths. We own our decisions and choices, and their consequences.
“Talent without discipline is like an octopus on roller skates. There’s plenty of movement, but you never know if it’s going to be forward, backwards, or sideways.” – H. Jackson Brown
We strive for excellence, and excellence requires discipline in little things on a daily basis.
“There is no such thing as a “self-made” man. We are made up of thousands of others. Everyone who has ever done a kind deed for us, or spoken one word of encouragement to us, has entered into the make-up of our character and of our thoughts, as well as our success.” – George Burton Adams
We grow through support and encouragement, which helps us spread our wings, improve, gain confidence, and reach our potential.
“We need to give each other the space to grow, to be ourselves, to exercise our diversity. We need to give each other space so that we may both give and receive such beautiful things as ideas, openness, dignity, joy, healing, and inclusion.” – Max de Pree
We know that too much sameness stagnates an organization, so we explore and leverage differences to open the door to possibilities.
“Courage does not always roar, sometimes it is the quiet voice at the end of the day saying “I will try again tomorrow.”” – Mary Ann Radmacher
The rewards are greatest when we take chances, risk exposure, and step outside our comfort zone. Leaders nurture and reward courage.
“The secret of life, though, is to fall seven times and to get up eight times” – Paolo Coelho
It’s not just a matter of having the will to get back up and keep on going. We must also have the “health” to do that. As an organization and as individuals, we take care of ourselves so we can continue to bounce back.
An organization which cultivates an environment like this, is one where people are important. And when people are important, they collaborate, they innovate, they adapt quickly to change, they “dare greatly”…..and amazing things happen.
Gee, that sounds an awful lot like an Agile environment!
What do you think?
Agencies around the government are beginning to see more and more of their employees teleworking and going to modified work weeks. There are a number of employees that work enough so that they can modify their schedules to be off every other Friday or Monday, or even every Friday or Monday. Due to a number of factors, many employees are also teleworking, or working from home. Sound like you or someone you know?
What does this have to do with Agile?
I hear very often that one of the most talked about, and even controversial, things about an Agile transformation is the idea that teams must all be in the same room in order to satisfy the 6th principle of the Agile Manifesto “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
If we take this principle into account, then we find that the telework and modified schedules turn this upside down and cause some confusion and concern on whether or not an agency can actually transition. I have had a number of federal employees, especially leadership; ask if they can really transition to an Agile culture. The actuality is “yes” – an agency in this situation, can most certainly transition to an Agile environment!
The biggest question for any agency is not “can we?”, but “how do we?”. The agency needs to start with the understanding that the 6th principle says that face-to-face is “the most efficient and effective…” way to communicate; it does NOT say that it is the only way to communicate. It is so very important to encourage face-to-face communication for those that are in the office on a daily basis, but not so important that they relinquish the teleworking or modified schedules.
The key is to have the agency give the teams as much encouragement and support as they can to help create an atmosphere that fosters communication and collaboration in many different ways. The agency will need to enable team members to communicate through means that may not have been ‘the usual’ in the agency. Many government agencies have never had to put a lot of effort into ‘unusual’ modes of communication and collaboration because either the employees have been in the office all the time and/or the employees have worked fairly independently. The more independently employees work, the less they need ways to communicate and collaborate outside of the ‘usual’ means of phone and email.
Agencies that need to step out of the ‘normal modes’ of communication are most likely very skittish of doing so for a multitude of reasons. Some reasons I have been told that agencies may be skeptical is the level of security that needs to be maintained in the agency; most agencies will admit their security levels are much higher than those of private industry. Because of the level of security that needs to be supported, many obvious communication mechanisms are overlooked or pushed aside without fully investigating the overall options.
However, in today’s technological age, there are many options that are available. Any agency that is looking to transition to a more collaborative environment, one in which Agile can flourish, needs to look beyond names and find what works. They should start by understanding the needs of the teams and work with the teams to find solutions, such as Office365, webcams, bridgelines, etc.
The one thing that agencies should never assume is that they cannot transition to an Agile environment simply due to these modified schedules or teleworking situations. It all comes down to support and encouragement of teams made of people that are not all sitting in the same location…something that many agencies have not had to deal with before now!
Have you been in this situation? Do you know some that are? What do you, or they, think can be done to be more collaborative?
Being always busy does not always mean being productive
As often happens at the end of a calendar year, many people reflect on the past and start thinking about what would make sense to do different in the future.
Recently, I was having such a contemplative conversation with a client. He asked me if I am seeing any trends with management practices that, while put in place with good intentions, have unexpected consequences or side effects. He wanted to understand if his organization’s challenges in meeting delivery date commitments and accelerating time to market are rooted more in something they do versus something they don’t do.
Utilization Vs Throughput While there are many trends I could talk about, there is a common pattern I have seen not only in the past year, but for the past twenty years. This pattern is prevalent in silo organizations and is usually a result of good managers doing what they are expected to do: keep systems running and control or minimize costs, while maintaining organizational commitments. If managers do these things, they are “managing well”.
One way to minimize cost is to minimize waste. What do we consider one of the biggest wastes in our environments? Idle resources. We don’t want idle resources because it feels like we’re wasting money, like we’re paying them “for doing nothing”. So, managers often aim for departmental efficiencies by focusing on maximizing utilization of people in their department. In knowledge work fields like software engineering and information technology, this practice is frequently used to minimize costs within a department.
While controlling personnel costs is managed at the department level (e.g. Product Management, Project Management Office, Development, Test, Operations, Support, etc), maintaining organizational commitments can be achieved only through synchronized efforts across departments.
Although not readily apparent, this creates a conflict because the organization’s throughput is deeply affected by the flow of work through the whole system and has nothing to do with local, departmental efficiencies.
Stop Managing Locally, Start Managing Globally Maximizing resource utilization at the local level does not necessarily support an enterprise or systemic (i.e., global) optimization of getting products or services to market as quickly as possible. Quite often there will be departments with minimal slack time because the people are fully utilized, yet they are creating long delays for other departments. While everyone is very busy (and that makes us feel good), projects seem to take forever to be completed, or are completed so late that market opportunities are missed.
As long as we manage a complex production system such as an IT organization by breaking it down into department subsystems, and we manage these subsystems individually, we’ll continue to find it difficult to achieve significant jumps in throughput or profit within a relatively short time (months). The fact that each subsystem is optimized does not mean that the flow through the system is optimum.
Managing departmental costs means making management decisions according to local efficiencies, whereas managing commitments and reducing time to market requires management decisions according to global efficiencies. In other words, to manage, improve, and predict the output of an organization, we must be able to understand and optimize the flow of work through the whole organization and NOT the local efficiency within each department.
A Fundamental Shift
The shift in thinking required to manage globally vs locally is significant for many organizations, and starts with the leadership team.
However, the inability to make this change throughout an organization is a common cause of failure when trying to increase throughput, improve adaptability, and achieve enterprise agility.
Does your organization have a lot on their plate?
Are resources spread too thin?
Have you heard the phrase “stop starting, and start finishing”, but aren’t sure how it applies to your organization?
If you answered yes to any of these questions, here is an analogy to help you describe why prioritizing and concentrating on fewer projects first is important. It’s okay to not start everything at once.
In Detroit entire blocks of houses sit empty.
Imagine we have formed a consortium to buy a cul-d-sac of houses. We have a fixed budget. The houses all require work before they can be rented or sold. Our vision is to do the work, and start receiving an ROI on our investment by selling, or renting the houses. Our budget includes money for the initial purchase, and repairs.
We divide and conquer. We look at each house and identify everything the houses will need to make them wonderful homes. Each of is assigned one or more houses to work on. We utilize our skills, and hire contractors to backfill our team to get the work done. We have more houses than project managers/leads, so we must spread ourselves out across many houses. It is a slow process, but all houses should be done in 12 – 13 months. Then our inspectors (QA’s & PO’s) will need to sign-off on all the houses, we will need to remediate any issues, and then finally we can start to do something with everything we finished.
While we are working on the houses, our specialist like plumbers and electricians are spread thinly across the project too. It is hard to schedule their time, and we have down time while waiting for them. Even worse than the down time, is the fact that while they are running from house to house trying to get things done, they aren’t as thorough as they should be. We find ourselves calling them back, cleaning up after them, or just don’t know that something was missed until the property is inspected. They suffer from task switching and trying to make everyone happy at the same time.
Everyone is stressed, progress is hard to see. Leadership pushes for more, and the teams become dissatisfied with their job.
We rank the houses by Return on Investment (ROI) or Weighted Shortest Job First (WSJF – considering job size, sunk costs, and cost of delay), and all of us begin work on the house(s) with the biggest ROI/WSJF. When the first house is finished we can immediately sell or rent it, moving on to each subsequent house completing them with dedicated resources until all houses are complete. Worst case, the last house is not complete for 12 or 13 months, however we have been receiving money from the first house for 10 months, and each subsequent house as completed. By the time we get to the last house, we may decide just to bulldoze it and build a park.
We welcome change. More importantly, we can choose to change. We haven’t wasted any work identifying what will be done ahead of time. We identify what we need for each house “Just-in-time”. If there is a new “green” lighting system available, we can choose to change the plans and use it. If we decide to add heated flooring in a particular area of the next house, we can. Furthermore, we can decide if it makes sense to include these items in other houses based on the impact to just one house.
Our rework on each house is minimal. Our teams get faster at doing their work the longer they work together as a team. Everyone sees constant progress towards a shared end goal.
We have our supporting infrastructure in place. We know who is responsible for the work, and can trust everyone to do their best. The team gains positive momentum, and direct feedback. Everyone sees progress. We follow Lean and Agile Principles to ensure our teams are happy and fulfilled with their job.
One of the hardest things for companies transforming to Agile to accept is the idea that team members are to be dedicated to the teams to which they are members. When it comes down to it, it is really about the cultural shift.
In order to better understand what the cultural shift is, you must first ask yourself: “do I know what a team really is?” A team is defined as “a small number of people with complementary skills, who are committed to a common purpose, performance goals, and an approach for which they hold themselves accountable.” Teams that are geared toward the same goals are much more productive and are said to be able to accomplish more together than individually— “T.E.A.M. = Together Everyone Achieves More!”
Traditionally, when we discuss teams, we talk about them in the context of project teams. However, there are a few things about ‘project teams’ that cause us to pause as we refer to the definition of what a team really means.
One of the things about ‘project teams’ that cause some dread is the fact that project team members are not fully dedicated to the efforts of the one project team. In most cases, each member ends up being a member of multiple project teams. As members become members of multiple teams, their focus is interrupted and therefore undermines their commitment to each of the ‘teams’ they are a member of. It becomes hard to hold yourself accountable when you feel an obligation to commit to multiple teams, which usually will have different goals!
Another thing about ‘project teams’ that poses some stress is that they are only together for a short period of time then the members disperse and join other teams. When this happens, they now have to build their commitment and goals, as a team, all over again. If teams must continually come together then are broken apart, sooner or later the commitment to the team means nothing. Each time the team dynamic changes, the productivity of the team goes down and very seldom has time to recover before there are more changes.
How does this change with Agile, you ask…
As organizations move toward a more Agile-driven one, how they ‘build’ teams becomes very important. One of the main goals of Agile teams is that they are geared toward a specific backlog, which is centered around a particular product. Once the team is set with the members, they have the ability to rally around the backlog and focus on that.
When building teams around a specific backlog, or product, it is easy to have them focus on the single team that they are members of. Using this idea, the members that are on the Agile team are all dedicated to the same goals and outcome. When this happens, the members have a higher level of commitment because they are dedicated to the one team and can focus on the goals of that team and none others.
Agile teams that are geared toward a specific backlog, or product, have no reason to be dispersed at the end, because there is no end. Because a backlog, or product, is for all purposes, never-ending, the team keeps working on the backlog and the organization, in some way, keeps the backlog full with things that the product needs to have or do.
As the culture shifts from one geared toward the traditional definition of team to the Agile team concept, their focus and commitment shifts. It is the organization’s job to support the change in the team structure and help to keep the team focused on the idea that “T.E.A.M. = Together Everyone Achieves More!” holds true!
Tune in next time, when we talk about what it means to be a cross-functional, dedicated team…