Lead Time (est. 3-min read)

TL:DR Limiting WIP has an exponentially positive effect on reducing Lead Time.

User story lead time was recently added to my client’s reporting system, to be used by Scrum teams. Story Lead Time (LT) is the average number of days from the story creation data to its finish in a completed sprint, meaning LT = (Completed Date - Create Date).

Some of you might be thinking, "So what? Sounds like a metric that a manager can use to make me work harder." If that's the way you (or your manager) think about metrics, this is likely to result in very unfortunate behavior (see Goodhart's Law, Campbell's Law, and the Hawthorne Effect).

To wit, if my goal is to reduce Lead Time, I need the Create Date to be closer to the Completed Date. There are many ways to do this, but two that I have heard already this week are:

1. Have a "shadow backlog" outside of Jira. When the squad is ready to work on the story, add it to Jira. Voila!

2. Compromise the Definition of Done, specifically sacrificing quality and cleaning up Technical Debt in a "hardening sprint". Ugh!

Of course, neither of these tricks will actually reduce the Lead Time. They are designed to game a system that doesn't exist. It is a complete misunderstanding of the purpose of measuring Lead Time.

The purpose of measuring Lead Time is to shorten the customer feedback loop. When we say that "lead time starts with a request from a customer and ends when the value is delivered to that customer", we remind ourselves that our purpose is to deliver value to customers and to get their feedback so that we can deliver even more value to them. The purpose of delivery is learning, and the more frequently we deliver, the more we learn. Thus, shortening the feedback loop (i.e. lead time) will increase our learning.

If you're still with me, your next question might be, "How do we shorten our Lead Time without working harder or faster?" To answer this, it is important to understand what Lead Time is, especially the law that governs it: Little's Law. I won't bore you with the origin of Little's Law in queuing theory, but here's a decent primer if you are so inclined. I'll keep it simple for our purposes.

Little's Law in software development says that

Lead Time = WIP / Throughput

WIP (Work in Progress) is the number of items being worked on by the team. In software development the unit of measure could be user stories.

Throughput is the departure rate and in a stable system it is the same as the arrival rate of Little’s original formula. An example of Throughput is five user stories per week.

Using that formula, there are two ways to reduce the Lead Time:

1. Increase the denominator (throughput) by delivering more things faster. Presumably you are already working hard at a sustainable pace, so there probably isn't much we can do about the denominator.

2. Decrease our numerator (WIP). The simple act of doing one thing at a time will reduce your Lead Time. The best part is that the relationship, while appearing to be linear, is potentially exponential!

Again, I won't go into the details of the high cost of task switching. Suffice it to say that for every task or story you have in progress at a time, you are losing gobs of throughput(!) every time you switch between them. Therefore, if we reduce our WIP, we are having an indirect (but very real) effect on throughput. In other words, reducing WIP is a way to positively affect our numerator and denominator at the same time, thus reducing our Lead Time!

Let me know in the comments what metrics you use to signal a need to change the way you work.

4 Steps to Self-Organized Teams

With a nod to the guys at Freakonomics, what do birds, soccer, and Agile Teams have in common? They are all examples of spontaneous order, or self-organization.

• Flocking behavior is a form of self-organization found in nature. Flocks have three simple rules: separation, alignment, and cohesion. With just those rules, the flock is able to move as if it were a single complex organism. Consider: hundreds of birds taking off and flying in a tight group, wind swirling — this should be total chaos.
• In soccer, players are assigned positions (roles) and are told their responsibilities. Once the game starts, the players have to adjust to the other team’s moves. Players have to trust that their teammates will move to the right places, pass the ball at the right time, and shoot on net when appropriate. The coach has very little control during the run of play, and the referee just observes for compliance purposes. The team is responsible for the results.
• An agile team operates under the Agile Manifesto and the supporting principles, one of which is this: “The best architectures, requirements, and designs emerge from self-organizing teams.”

That’s easy to say, but what are self-organizing teams? How can you create a container in which teams are more likely to self-organize? What do we mean by “team” anyway?

Four main attributes of a real team

Teams have a common purpose

Ask yourself: does my team know the mission and vision of the project? Do they know how that vision fits with the strategic direction of the company? Can they see a direct line between the stories and tasks in each iteration with the Project Charter and Business Case? Does each iteration begin with a review of the goals for the next release?

If your answer to any of the questions is “no”, why not? What makes you think the team can self-organize and deliver good results if they don’t know why they are doing it? What is their motivation?

Teams have clear boundaries

We can’t expect teams to self-organize without knowing what the limits are. The team knows the extent of their authority in terms of information flow, alignment with other organizational units, resources or decision-making policies. In a regulated environment, some boundaries are very clear and necessary. However, some limits are arbitrary or are there because “that’s the way it’s always been”. Teams should be encouraged to question every limitation. A team that knows the limits, and the reasons they exist, will be better able to operate effectively within them.

Consider whether your teams ask questions or simply follow your lead. What are some techniques you can use to encourage questions? One possibility is to use a POWER (Purpose, Outcomes, WIIFM, Evaluate, Results) agenda for meetings allowing your team to prepare questions ahead of meetings. Try statying quiet for longer than you normally would. Use the WAIT acronym to always ask yourself: Why Am I Talking?

Teams stay together

The third feature of real teams is stability over some reasonable period of time. What happens if I remove any of the rocks in this structure? Any change in the structure forces rebuilding from the beginning. Even though (with each change in the team) they might become more efficient at Forming, Storming, and Norming, on the way to Performing, they still have to go through every stage. A team in constant turmoil, with frequent turnover, is unlikely to perform at a high level. The team almost definitely will not reach a predictable velocity, and so cannot really improve in a methodical way.

Teams have authority

The authority to self-manage within the given boundaries allows the team to use all of its experience and expertise and creates an environment in which emergent design can thrive. This type of freedom leads to the simplest solutions to the business problems.

How do you “grant” authority to the team? Ask more questions, instead of giving answers. Believe me when I say that Agile Coaches have opinions about technical decisions made by teams. I think one of the hardest parts of our job is staying silent when we disagree with a team decision. The Scrum Master’s role is also to let the team make decisions. You can’t let them make disastrous choices, but you should let them choose options with which you disagree. There are multiple feedback loops built into Scrum that will let you and the team examine whether the choice works out. Even though you might have some technical expertise, giving technical advice is not the role of the Scrum Master. If “technical expert” is a secondary role for you, make it clear when you are taking off your Scrum Master hat and putting on your technical hat. Some Scrum Masters literally use a hat to indicate the role change.

When deciding the limits of the team’s authority, you need to consider who is best able to handle the functions of the unit.

Four main functions of an organization

Setting direction

Teams need someone to set the directions for the team, i.e. specifying the organizational objectives, the core purpose or mission that requires the tasks so that they are all pulling on the same direction. Typically, that is the Product Owner, but that role is a Scrum construct and doesn’t necessarily exist on every team. In any case, your company might have Product Owners, Chief Product Owners, Application Owners, Executive Sponsors, and other stakeholders who probably have part of the mission, vision, and direction. The team needs to know who the single voice is on the subject of direction.

Organizational design

The second function of an organization is for someone to be responsible for designing the performing unit and arrange for needed organizational support for the work i.e. structuring tasks, deciding who will be involved in performing them, establishing norms of conduct for work behavior, and making sure teams members have the resources and assistance they need to carry out their work. Some of this might be the Scrum Master’s job, but some can be performed by the team. The more that the team handles on its own, the more likely they are to be committed to the work.

Monitoring performance

Teams need to determine who is in the best position for monitoring and managing the work process, i.e. collecting and interpreting data about how the work is proceeding and initiating corrective action as needed. Scrum provides some standard tools for measuring progress, some that will automatically generate useful information when used correctly. However, none of that matters if the team isn’t looking at the data and taking action. The theory behind Scrum is empirical process control, and the pillars that support that theory are transparency, inspection, and adaptation. To be blunt, teams that aren’t using the data to improve their processes are not doing Scrum. Teams that don’t know how to use the data can’t do Scrum. Make sure your teams know what information is important, how to interpret it, and what actions are appropriate based on what they are seeing. Either your iteration review or retrospective are a perfect setting for examining the data and discussing trends.

Oh yeah, getting stuff done

Of course, the fourth function of an organization is someone to execute the work, i.e. apply physical or mental energy to accomplish task. That should be almost everyone on the team, but it is worth noting who is involved in the work each iteration. A team will find it difficult to self-organize if they aren’t clear about what each person is willing and able to do.

Motivation

Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself. – Ken Schwaber

If we accept Ken Schwaber’s words as true, then how do we create a context in which team responsibility for commitments is more likely to emerge?

Give them the information

More and more, I see teams trying to shorten the iteration planning. They don’t find the time valuable because they are given a set of stories and are not encouraged to ask questions unless there is a technical concern. A high-functioning team loves the planning process because it is the best time to ask powerful, probing questions. Technical expertise comes from curiosity, but we stifle curiosity when we don’t examine why a customer needs a certain feature or function, and we stifle creativity when we don’t examine alternatives to developing a minimally viable product. More information = more motivation.

Give them resources

Teams will find it difficult to self-organize around the work if infrastructure is an impediment. Applying some variation of Maslow’s Hierarchy of Needs, organizations should be examining the basic items teams need to continue to exist in a healthy way.

Give them education

Teams need training, coaching and technical assistance. In the hierarchy of needs, this is a level above the basics, but it is critical to project success. We talk a lot about cross-functional teams, but we don’t mean that everyone on the team is interchangeable. We mean that a Scrum team has all the capability to produce working software without depending on outside support. This is not always possible, but teams should be striving to move closer to independence with every iteration.

Give them rewards

The idea of economic, or even symbolic, rewards has been shown to be demotivating according to studies conducted in the past decade. Daniel Pink wrote about another way to motivate employees in his book Drive.

Autonomy – Employees desire autonomy over the main areas of their work. The want some control over time (when they do it), technique (how they do it), and task (what they do).

Mastery – Employees want to become better at something that matters to them.

Purpose – Employees desire to contribute to a cause greater and more enduring than themselves.

Keep in mind that increasing employee satisfaction through self-determination has an effect on traditional compensation models. I’m not suggesting that your organization must immediately change its financial reward system. I am suggesting that that system may not have the intended effect and that supplementing it with modern ideas about motivation is worth considering.

So if we:

1. Give our teams a compelling mission and describe the product vision;
2. Surround our teams with the appropriate sub-systems:
   • Reward and Information to motivate and propel them,
   • Education and Infrastructure to enable them;
3. And create a container in which the team:
   • Develops goals, guidelines and policies,
   • Takes advantage of the broad range of knowledge, experience, education, age, gender, and cultural backgrounds,
   • And freely exchanges information;

we are more likely to have a team that can easily respond to change. What’s stopping us?

Change is hard

Many factors highlight the need to change how organizations are run. To become more agile, we need the power and authority to be with the people closer to the customer. We have to trust them with information and give them time to think, learn and improve. At the same time, bureaucracy needs to be reduced if not eliminated. We need to be Lean.

The only way to achieve these goals is to empower our teams. We have to allow them to use their expertise, not just to execute their work but to monitor and control themselves, make their own decisions and design their processes.

Situational Leadership model

As the organization and teams mature, we need to change our leadership behaviors from highly directive (lower right on this chart) to coaching, supporting, and eventually delegating responsibility.

High Directive

• Set goals
• Organizing
• Define time boxes
• Give directions
• Check up (control)

Low Directive

• Supply support
• Communication
• Collaboration improving
• Active listening
• Give relational feedback

First steps toward self-organization

Overcoming inertia, i.e. taking the first step, is always the hardest part. It is especially difficult when you don’t know what the first step should be, so I’ve drafted a list of some first steps you might consider in your organizations.

1. Make sure teams understand the mission and vision and their part in making it happen
2. Talk about boundaries in terms of information flow, alignment with other organizational units, resources or decision-making policies
3. Do whatever possible to stabilize the team structure and maintain it
4. Decide, with the team, who has the authority to:

• Set the directions for the team
• Design the team and get organizational support for the work
• Establish norms for work behavior
• Make sure teams have the resources they need to do their work
• Collect and interpret data about how the work is proceeding
• Initiate corrective action as needed
• Execute the work

I hope you find this article useful on your path to self-organized teams. It is important to note that self-organization can’t happen overnight: The Neuroscience of Agile Leadership.

Please subscribe and share this blog using the widgets below and Follow me @QuietAgilist or Connect with me on LinkedIn to get updated when I post a new entry. It's free with no obligation!

What is Agile?

When people hear the word ‘agile’, what immediately comes to mind is a software development methodology like scrum, XP, and Kanban. They might think about iterations, sticky notes, and daily stand-up meetings. But agile is so much more than tools, techniques, and structures. In fact, you could say that agile exists in spite of all the structures companies put around it. Agility means having flexibility to navigate around constraints and unknowns.

The Agile Manifesto originally applied to software development, but that was just a mistake of history. The original signers were programmers, so they talked about the values and principles in terms of software. However, they almost immediately discovered that the values and principles apply to any product development, particularly in knowledge work.

Agile is a mindset of learning and discovering how to manage uncertainty. The four Agile values tell us how to efficiently learn and discover in the software domain. Taking each in turn, we can learn and discover more from individuals and interactions than from processes and tools. We can reduce uncertainty more efficiently by looking at working software more than by looking at a set of documented specifications. Clearly more can be learned via collaboration with customers rather than the adversarial perspective given by contract negotiation. Finally, there can be very little learned and discovered by following the original plan; much more is gained from responding to change.

The Agile values are supported by twelve principles that help us make sure that learning and discovery is happening in our organizations. Each of the principles has a message about behaviors that guide project teams to continuously learn and discover better ways to deliver a working product. While there isn’t necessarily a direct mapping between the values and principles, I find it helpful to view each principle as especially supporting one of the values.

Individuals and interactions over process and tools

Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.

Daniel Pink, in his book, Drive, lists three elements of the motivation formula: autonomy, mastery, and purpose. In situations where people are paid fairly, this trio drives, engages, and stimulates us to do our best work.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Long hours make us less, not more, productive. Allowing that there will be occasional exceptions, overtime only serves to cover up for schedule, management, or quality deficiencies. Working overtime to fix a symptom of broader issues only enables the broader issues to continue without penalty. The Agile approach exposes these deficiencies as early as possible and remedies their causes, rather than treating the symptoms.

The best architectures, requirements, and designs emerge from self-organizing teams.

The essence of emergent design is that we start with what we know, create an initial design, then extend the design as we learn more. Self-organization, also known as spontaneous order, is the spontaneous emergence of order out of seeming chaos.  These two ideas, emergent design and self-organization, are at the heart of valuing individuals and interactions over processes and tools. Software development, as well as other knowledge work, is a creative endeavor. Prescribing the use of certain tools and adherence to processes tends to hinder creativity. Teams that organically form around the work are inherently creative and driven by the three elements of the motivation formula.

Working software over comprehensive documentation

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Agile development is a series of experiments. There is really only one way to know if a product works: use it in the same way as the customer would. There is also only one way to know if what you’ve built is what the customer actually needs: use it the way the customer would. With that in mind, the best way to test the product is to use the customer. This is no different from traditional product development in that the true test happens when the customer uses the product. The difference with Agile is that we want the customer to test the product early and often, so that we don’t waste development time and money on a product they don’t want or can’t use. So we develop iteratively – we develop something that works, but it may not have all the features or formatting yet. We give the customer something to test as soon as we produce something that appears to have a use.

Working software is the primary measure of progress.

Agilists are concerned about cost and schedule constraints, but when we want to know if our projects are going well our first metric is the amount of value delivered to the customer. We are concerned with whether the rate of delivery is increasing, whether the customer still thinks the value delivered outweighs the cost of delivery (read: cost/benefit analysis), and whether the quality of the product allows the team to continue to deliver new valuable features (i.e. no re-work).

Simplicity -- the art of maximizing the amount of work not done – is essential.

"Make everything as simple as possible, but not simpler." - Albert Einstein

There is a Lean concept that says you don’t want to waste your time and money building a product no one will want to use or pay for. The idea is to build a product that allows a team the maximum amount of learning and discovery with the least effort. This is referred to as the Minimum Viable Product, or MVP. Part of making sure you expend the least amount of effort is to do the simplest thing in the simplest way. We want to give the customer something to react to as soon as possible, so we don’t want to spend too much time making our software code perfect. We are more interested in whether we have built the right thing, and then we can worry about adding more functionality and complexity based on the customer needs.

Continuous attention to technical excellence and good design enhances agility.

“Simple” does not mean bad, though. Unsustainable and poor-quality product development contradicts and reduces agility. Architecture that is poorly conceived or is not aligned with the product vision will hinder the changes you want to make. Misaligned architecture will work against the team and its growing understanding of the system’s purpose and realization.

Customer collaboration over contract negotiation

Business people and developers must work together daily throughout the project.

Shorter feedback loops are necessary when trying to discover the MVP. The most immediate feedback is available when the customer and the development team are always connected.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Requirements gathering, clarifying questions, product demonstrations, feedback, peer review. Stop me when you read a type of interaction that is better from a distance, over the phone, or via email. Multiple studies have proven the value of face-to-face conversations, especially in the area of non-verbal communication.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Early and continuous delivery is the basis for better ROI from agile projects over traditional projects. In the end, the agile project might cost just as much and take just as long as the traditional project. In the traditional project, the benefits will not be realized until all the requirements have been met and the full product is released. The ability to use a version of the agile product sooner to begin receiving some benefits to offset the costs is a huge difference in ROI.

Responding to change over following a plan

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Transparency, inspection, and adaptation are the three pillars of Scrum and they apply to all Agile product development. Traditional projects conduct lessons learned meetings, sometimes referred to as post-mortems. These happen when a project is over and the team is disbanding, which means the “lessons” will not necessarily apply to the next project and team that each person joins. Teams that frequently review recent performance , communication, and collaboration, and then take action based on their discoveries is likely to be more effective.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

There are several reasons to welcome change during the execution of the project. First, businesses don’t stop changing just because there is a project happening. To be competitive, we need to allow for changes during mid- to long-term projects. Second, our understanding of the business problems can change during the execution of the project. In some cases, new insights can change the solution in a positive way. Finally, we need to be open to emerging technologies that can be part of the solution.

The product architecture has to be able to support changing requirements. The architecture should be flexible enough to support implementation of changes and robust enough to stay stable during development. To align the final product with customer needs, changes must be seen as a possibility and not as a way to delay and complicate a project.

Being Agile

Agilists are informed by the values and guided by the principles, but there is virtually no limit to ‘agile’ practices. This fact is critical to understanding what agile is, because as soon as there are limits placed on practices, agility itself is limited. As an example, Scrum is one set of practices that stand under the Agile umbrella, as is eXtreme Programming (XP), but if a team or individual does not think beyond the rules of the Scrum Game, they are not agile. We say that those people are ‘Doing Agile’ because they approach Agile as a process and a set of practices.

Being Agile means approaching Agile as a mindset and culture, internalizing the values and principles, so that the adoption of particular practices is based on the usefulness under the current circumstances, not because there is a prescribed process that teams must follow. It is relatively easy to get a team or company to rigidly follow a set of practices like those described in Scrum or SAFe. The problem is that projects are not predictable, so people must have agility to adapt to the inevitable changes. Mastering basic practices should be a starting point to becoming Agile, not the end of the journey.

Why Agile?

In the course of our work, of course, there are people who just want to be told what to do. They want a checklist of practices so they won’t need to think. This is a task-based mentality and works fine on an assembly line. With an assembly line, task workers know what is going to be produced; in fact, there are controls in place to make sure the final product is well known before work begins.

On the other hand, knowledge workers want to know the context of the work, the reason for the work, and want to innovate to produce better products. Knowing why our work is needed is important to knowledge workers because the exact outcome of the work is not knowable until the work is done. This is not to say that there is nothing known when knowledge workers begin, but it does mean that the exact final outcome is not knowable in advance. Whether doing software development, finance, marketing, education, or even some type of operations, most people are knowledge workers.

In addition to the outcomes being unknowable, knowledge work also involves more intangibles than task work. The person who builds a house uses a finite supply of tangible materials. In that circumstance the cost of changes is very high. The person who builds software is producing code, which has no practical limit and has a very low cost of changes. The Agile values reflect the idea that the best outcomes are achieved if decisions are made as late as possible, waiting until the last responsible moment so the customer is certain to get what they need.

Flexibility, transparency, inspection, adaptation, autonomy, mastery, purpose…there is no limit to the attributes of a master agilist, just as there are no limits to what a truly agile team can accomplish. Constantly striving for better, higher, faster – that is what Agile is.

Please subscribe and share this blog using the widgets below and Follow me @QuietAgilist or Connect with me on LinkedIn to get updated when I post a new entry. It's free with no obligation!

My Greatest Fear? Unconscious Incompetence

"...when people are incompetent in the strategies they adopt to achieve success and satisfaction, they suffer a dual burden: Not only do they reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the ability to realize it." - D. Dunning and J. Kruger

Ignorance is Bliss

I first read about the Dunning-Kruger Effect in a January 2000 New York Times article titled, "Among the Inept, Researchers Discover, Ignorance Is Bliss." I have been carrying that article around with me since, using it as a daily reminder to never be complacent.

Don't get me wrong, I have no problem with incompetence. Like everyone else, I am incompetent at far more things than I will ever be competent at. My concern is that, among the few things I believe I have achieved some level of competence, I could be delusional. Before going deeper into my fears and delusions, let me tell you what is meant by unconscious incompetence.

First developed in the 1970s, the Four Stages of Learning says that individuals are initially unaware of how little they know, or unconscious of their incompetence. Once they become conscious of their incompetence, they consciously acquire a skill. After much practice and continued use, the skill can be used without consciously thought (i.e. unconscious competence).

Consider an example: learning how to drive.

Sitting in the backseat as a kid, you don't realize all the skills required to safely drive a car. This especially true if your parents had a manual transmission. You could just sit in your booster seat, turning your toy steering wheel, thinking how easy it is to race through traffic. You don't know about the clutch, checking your mirrors, anticipating other drivers' moves, etc. You are obviously incompetent to drive, but you are also unconscious of that fact.

When you get your learner's permit and your parents take to a parking lot for your first driving experience, you quickly learn that you don’t know how to do it (conscious incompetence). That consciousness presents you with a decision: is this a skill worth learning or should I spend my time on something more valuable to me?

It is the rare 16 year old that decides anything is more important than driving, so you start to practice. As you practice you need to think your way through every movement of driving. This is the conscious competence stage. The fact that new drivers need to focus on every task is a major argument in support of laws against using cell phones while driving.

After hundreds of hours behind the wheel, driving becomes a habit. Eventually you can drive without thinking, shifting gears effortlessly while thinking about other things or conversing with your passengers. The point when a skill becomes second nature is called unconscious competence.

So what does this have to do with fear and delusion? The fact that I can write about this is evidence, to me, that I am self-aware and know my limitations. But what if self-awareness is my blind spot and I actually lack the skill to know my limits? It's a vicious cycle.

AVOIDING BEING UNCONSCIOUSLY INCOMPETENT

Inoculating yourself against this cycle begins with the understanding that you can never achieve unconscious competence in self-awareness. This is an area that requires focus and constant vigilance. You have to be brutally honest with yourself and ask yourself on a continuing basis, "Am I the best person available to complete this task? Do I have all the necessary skills and knowledge to do the work? If not, what am I missing?"

When you are not brutally honest with yourself,  you need to find someone who will be. We all have our blind spots. Who is that honest person in your business life who will speak the truth to you?

If you lack competence in some areas, consider whether you need to. Then take the steps to gain new competencies.  Education doesn't end when you leave school.  Whether formal or informal, there are an endless number of ways to learn what you need to know.  Reading can be a source of entertainment and education. Meeting regularly with a mentor is a great way to identify gaps as well as maintain important connections. Professional associations (like Scrum Alliance) have regular meetings, and professional development groups (like Toastmasters International) expose you to new skills you may not know about.

You can get 360 degree feedback from your colleagues. They are the people who see you in action every day and can provide the best feedback. You can also ask your direct supervisor for frequent feedback.

Finally, look at the key performance metrics related to your job.  If you are not meeting expectations or are lagging behind your peers, it could reflect a lack of competence.

Are you serving in a job that maximizes your competencies? Who do you have in your life that will help you evaluate your work performance? What areas of your performance do you really need to target for improvement?

Please subscribe and share this blog using the widgets below and Follow me @QuietAgilist or Connect with me on LinkedIn to get updated when I post a new entry. It's free with no obligation!

I'm Not Coming to Your Bad Meeting

I am not really a pet person, but I do collect peeves. One of my pet peeves is bad meetings. 

I have been known to refuse to attend certain meetings. I have even instructed people who worked for me to refuse to attend meetings if they didn't meet our standards. At a minimum, I try to remind people who invite me to meetings that there are certain things a meeting organizer must do to get full participation. Sometimes that makes me seem difficult, rigid, or even arrogant. I prefer frugal.

I find it incredible how much time we spend in meetings with nothing to show for them. Common sense tells me that businesses wouldn't tolerate the amount of time and money wasted in unproductive meetings but, of course, I would be wrong. For some reason, bad meetings are accepted as part of corporate culture. If I do nothing else in my life, I hope to eradicate bad meetings in my world.

In an earlier post, I used the Dwight Eisenhower quotation about planning, so I won't restate it here. However, it is good for almost any occasion. There are many reasons why a meeting goes bad, but almost invariably, the meeting never had a chance because it wasn't well planned. With all credit to my friends at the Agile Coaching Institute, a meeting has a better chance of success with a P.O.W.E.R. start.

A meeting plan starts with the purpose (P). If the facilitator can't articulate the purpose of the meeting, there is no reason to continue planning it. The purpose doesn't need to be detailed, but there does need to be an overall rationale for the meeting. If the best you can come up with is, "Because this is the weekly status meeting, and we have it every week," you are missing the point. Even recurring meetings need a clear purpose. Otherwise, they are just bad habits that need to be broken.

Going deeper into the purpose of the meeting would be helpful for attendees to prepare. For that reason, facilitators should consider the outcomes (O) and deliverables they expect from the meeting. If there will be any templates used or if there are examples of the deliverables, share them ahead of time.

As the facilitator is building the guest list, consider that every person will think about one thing before they accept the invitation - the dreaded acronym within an acronym: WIIFM (W), what's in it for me? This is not entirely a selfish thought on their part. How can you expect a creative and collaborative environment with people who don't know why they even care about the outcome of the meeting? Let invitees know what their takeaway will be and they will come motivated, and maybe even excited, to get the most benefits from the meeting.

Of course, sometimes the problem is knowing what participants want to get out of the meeting. You could guess, or assume, but you know what that gets you. How about the simple approach? Engage (E) your participants in the planning. The easiest way to build an agenda everyone can believe in is to have them build it. They can at least share their personal objectives for the meeting so you'll know if you are on the right track. Engaging them early in the process is also a good way to vet your guest list. The initial group of invitees will tell you if you have missed anyone, or if someone you included should actually be left out. Then, once you have heard from everyone, check in one more time to be sure the agenda will meet their needs.

The last part of your P.O.W.E.R. start should be well-known at this point in your planning. Each of the participants has a role (R) and responsibilities. Make it clear what everyone is empowered to do. You don't want anyone coming to the meeting thinking they have the authority to make decisions if, in fact, they don't. On the other hand, if the purpose of the meeting is to make a decision, you need to be sure you have invited people with the right authority.

All of this planning seems like it might take a lot of your time. Consider the alternative though: spending time in meetings without accomplishing anything, so that you need to schedule another meeting. Planning a meeting is an investment that pays off almost immediately. In fact, if the purpose is not clear and the meeting is cancelled, the planning does pay off immediately.

For recurring meetings, much of the work can be done once and only reviewed prior to the next meeting. While sprint planning, sprint reviews, and retrospectives would seem to be self-explanatory, wouldn't they be more effective if there was a clearly stated purpose right up front? A little reminder never hurt anyone. Those little reminders can lead to better attendance, a greater level of engagement, a quicker meeting, and consistently positive outcomes. With that kind of promise, I'll be there with bells on.

What are some of your pet peeves? What meeting techniques have worked for you? Let me know in the comments.

Please share this blog using the button below and Follow me @QuietAgilist or Connect with me on LinkedIn to get updated when I post a new entry. It's free with no obligation!

3 Proven Ways to Handle Dependencies in Scrum

Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment. - K. Schwaber and J. Sutherland, Scrum Guide, 2013

Except when they're not.

This topic is either ironic or timely, depending on your perspective. My last post was about the importance of vertically slicing stories. One of the most important elements needed to have all stories deliver working software is the cross-functional team. So let's just call this post an acknowledgment that the world is not perfect and move on.

Among the challenges of playing by the rules of the Scrum game is the problem of dependencies between teams. 

Scrum teams are responsible for development work, but they are frequently part of a large project or program. So, the individual Scrum teams are not able to create something useful for the enterprise. Their work must first be integrated with the work of other teams to bring real value to the business.

At least once per Sprint, all work must be integrated. The preference should lean towards continuous integration, but daily integration with other teams should be the minimum. At first, continuously integrating each team's work is challenging and your organization might not even have the capability. Companies have to change the development organization in order to integrate multiple teams' work. The technology used to build and test products must change and engineering practices throughout the organization have to improve.

Some changes happen within individual Scrum teams or even at the developer level. However, most companies need considerable improvements across the organization. We build very complex products, no matter how simple the design. Building working software every Sprint is difficult under the best circumstances, but nearly impossible without knowing daily status of development. IT organizations will usually take this opportunity to complain about what they can't do within Scrum, but they are focused on the problem while they should be focusing on solutions. Maybe they can't do everything right now, but with the right engineering practices, some discipline, a lot of drive to get there, it can be done.

Let consider some common external dependency scenarios and see how they might be handled within Scrum.

Front-end functionality depends on infrastructure enhancements

The MyReports team selected a Product Backlog item to allow a user to view all transaction types over a user-defined period in a single view. The current situation required users to export data from multiple screens so they could summarize the data in Excel. The project work comprised changes to the screens, workflow, and database.

The workflow and database was part of the infrastructure that supported many of the division's products. To support the user requests, there would need to be more frequent data capture and additional fields added. When those enhancements were completed, the user interface could pass a single request with the required account and time period variables. Unfortunately, infrastructure changes go through a different team, so the MyReports team needed to make a decision: (a) continue without depending on infrastructure changes for testing and demonstrations of the front-end enhancements, or (b) select another item from the backlog to work on until the infrastructure team was ready to work together.

Luckily, Agile gives us guidance for this type of situation:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - Agile Manifesto, 2001

So the only question the team needed to answer was whether option (a) would yield "valuable software." If the answer is yes, that would lead to a second question: is there really a dependency or is the infrastructure enhancement just preferable? In this example, the answer to (a) was no, so choice (b) was the only viable option.

Teams should not begin a story with an external dependency unless the other team is at the Sprint Planning Meeting to make their commitment. However, when a team supports the infrastructure enhancements for multiple customers, who prioritizes its work? One solution is an enterprise Product Owner who is responsible for overall ROI. By rolling up all the individual product backlogs into a single enterprise backlog, the uber Product Owner can prioritize the infrastructure Product Backlog to maximize overall ROI and minimize risk.

Work is divided by architectural layer

Sometimes it is not feasible to have development teams that are cross-functional across architectural layers. When working around this situation, don't lose sight of the three pillars upon which Scrum theory is founded: transparency, inspection, and adaptation. In order to inspect and adapt, teams always need to know where they are against the product backlog. Teams also need the ability to release working software as frequently as possible.

Amlar monitors financial transactions to identify suspicious banking activity. They deliver this functionality across five layers. The first layer collects and stores all transactions between banks and other entities. A second layer maintains client account information. The third layer maintains regulatory guidelines for financial transactions. The fourth layer compares transactions to regulations and creates message traffic. The fifth layer presents the messages as alerts for further investigation. Each of the layers was developed by separate organizations at different geographic locations: one layer in Georgia, one in New Hampshire, and three at different locations in Massachusetts. Each layer had its own Product Owner and development teams. The Amlar executives were pleased with the progress, but how did they do it? How do teams make sure they are adapting to changes, rather than continuing to build to the out-of-date specifications? How could each team know whether their increments would integrate into a useful product?

First, create an integration layer. Yes, a sixth! layer. The integration layer team had representatives from each of the other layers. The integration layer pulled the builds from each layer daily and tried to integrate them into a single build. Second, they developed integration tests  and exercised the functionality as it would be when the final product was released. Failures were reported to the layer that had caused the failure. That team had to prioritize the problem before ahead of any more development. Third, a norm was established that all layers had to integrate into a working increment by the end of each Sprint. If not, nothing could be called Done and nothing could be demonstrated.

Scrum team depends on waterfall team

HipaaCare sells health insurance and needed to replace its legacy systems with software that could adapt to the Affordable Care Act and other regulatory changes. One team was responsible for building a CRM system that would replace the legacy mainframe components for four customer constituencies. To pull the relevant claims and billing data into the CRM and to make the customer data available to other system, shared web services would be developed by a dedicated team.

The web services team was using its own milestone-driven process as it worked from the SOA design specifications. The milestones were a design document, a prototype of each service, and then the finished product. The prototype was a crude imitation of the final product, but it provided a test environment for the CRM and could be used to verify every Sprint's increment of functionality. However, the service team's delivery milestone was three months into the project.

The CRM team used Scrum and completed three Sprints within the first three months. It built a mock service to the specifications of the web service. Once the real service was delivered, development done on the CRM could be fully tested.

Change and miscommunication are directly correlated to product complexity. That is why Scrum requires integration to occur at least once per Sprint so it can be demonstrated at the Sprint Review. When other teams don't use Scrum, the Scrum teams need to integrate to the best possible representations of the other components. These representations must be devised and used to minimize later rework.

The CRM team had to build a simulation of the new service and structure as best as it understood it until the prototype was ready. They selected several enhanced functions and several new functions for the first Sprint. It refactored the design to broadly take the anticipated changes into account. It also ensured that the previously developed functionality continued to work.

This solution required the CRM team to retest its work against the best possible representation of the completed product. Every time the design changed, these representations had to be changed for retesting. The rework was limited to that functionality and the design completed when the change occurred. The real services from the waterfall parts of the project then would replace the Scrum team's simulation layer.

Conclusion

There are many reasons why teams are not cross-functional and self-contained, not the least of which is that many large organizations have adopted Scrum, but are not yet structured that way. There are also enterprise-wide systems changes that require some level of dependencies. Whatever the cause, there isn't a one size fits all solution. I think you'll find, however, that many situations can be worked using one of the three examples given above.

What issues have you encountered with dependencies? Have you found a solution that everyone can be happy with?

The Value of Vertical Slices: A Case Study (2nd of 2 parts)

In my previous post, I shared an experience I had with a scrum team in which vertical slicing made the difference between compliance with federal regulators. Below is a quick overview of why this approach is preferred and some simple strategies for splitting stories into small slices.

Horizontal vs. Vertical Slices

The design process is a series of steps that engineers follow to come up with a solution to a problem. Solving small problems is easier than solving large ones, so decomposing a large problem into a set of smaller problems is part of the engineering design process.

Horizontal Slices

The traditional approach to building a big feature was to decompose it into the work that had to be done at architectural layers. For a web service, we might break a feature down into the database components, the server components, and the client components. Often specialists in these areas would build their piece of the architecture separately, and then we would have an integration phase at the end where we would put them all together and test them to make sure they worked as expected. While this makes sense logically, and allows us to develop high expertise in one of the architectural layers, it tended to have a very slow feedback loop depending on the size of the feature, since we’re waiting for everyone to be done with their separate piece to integrate and make sure it works. The term “horizontal slicing” refers to using this architectural layer approach as the primary method of decomposition of big features.

Vertical Slices

In order to speed up the feedback loop, we take a large feature and break it up into several small pieces that slice through each of the architectural layers. It is possible to break down almost any feature into slices that take a couple of days at most to get all of the pieces built, integrated, and tested. Each slice is comprised of any work needed to be done in an architectural layer as well as any testing and integration that may need to be done to make it ready to release. In other words, the definition of done for each story includes all the work to make it potentially shippable.

Four techniques for vertical slicing

There are many different ways to vertically slice a user story. Here I show you four that cover most scenarios: Vague Terms, Conjunctions, Acceptance Criteria, and Workflow Steps.

Vague Terms

Sometimes we get user stories containing terms that are somewhat vague, which is ok since user stories are supposed to be “Negotiable” (see Bill Wake’s INVEST acronym). Vague terms often lead to possible vertical slices.

Example Story: “As a music listener, I want the device to store several hours of songs, so that I can listen to music when I don’t have cell service.”

Your first reaction to this story might be, “What do you mean by ‘several’?” The term provides an opportunity to slice by using an incremental approach. For example we might get the following slices by getting very specific:

1. Allow for storage of data equivalent to 10 hours of music
2. Store the 10 most recently played albums

Conjunctions

Conjunctions are words that are connectors: AND, OR, WHEN, IF, BUT for example. When there is a conjunction in a user story, it creates obvious opportunities to create a vertical slice.

Example Story: “As a music listener, I want the device to store several hours of songs and their identifying data, so that I can listen to music when I don’t have cell service.”

Notice that the “I want” statement of this user story has two parts: save the songs AND their identifying data. These are really easy to split into two slices:

1. Store the 10 most recently played albums
2. Store the identifying data associated with the stored music

Acceptance Criteria

Example Story: “As a music listener, I want create playlists so that I can hear songs that belong together according to my preferences.”

Now look at the acceptance criteria that the team building this story came up with:

1. Group songs in a playlist
2. Select order of songs in playlists
3. Allow songs to appear on multiple playlists

Notice that each of these criteria could become its own vertical slice, or in some cases multiple slices.

Workflow Steps

Another way to split stories is by thinking about how a user will interact with the system, and building one little piece of that interaction at a time.

Example Story:  “As a music listener, I want share playlists with my friends so that they can hear songs that belong together according to my preferences.”

We can break this user story into several workflow steps, each of which could be developed one at a time:

1. Create playlists
2. Group songs in a playlist
3. Select order of songs in playlists
4. Allow songs to appear on multiple playlists
5. Create friends list
6. Assign songs to playlist
7. Friends receive notification that I have shared a playlist
8. Friends receive link to sample songs in the playlist
9. Friends receive option to buy songs in the playlist

The advantages of vertical slices

• The smaller slices are much easier to understand, so there is greater likelihood of reaching consensus among team members.
• Estimates are generally more accurate for small stories.
• When we decompose into small pieces, we often realize that not every single piece is really required by the user.
• Smaller slices give us a faster feedback loop – we find defects in design, usability, code, and integration.
• People with specialized skills are not waiting while work is done in a previous step – with small slices, work is constantly flowing through the system.
• Small slices allow the team to get small wins on an almost daily basis, leading to greater engagement.
• Daily scrums become far more interesting and useful.

Conclusion

There are many good reasons why vertical slicing is preferred, not the least of which is to shorten the feedback loop. Sometimes the reason is because priorities change, communication breaks down, the market dries up, or the government regulators move the deadline date. Whatever the reason, vertically slicing stories with a robust definition of done allows the team to welcome changes at any point in the development cycle. 

The Value of Vertical Slices: A Case Study (1st of 2 parts)

The situation

Recently, a team I was working with had to react quickly to an unexpected software release deadline. The project environment is extremely complex (i.e. federal regulators, internal auditors, two outside vendors, three applications, multiple data sources, distributed team, compliance PMO, short- and long-term solutions in parallel, and more), so the fact that there was a missed communication is not surprising. Unfortunately, the missing information was that federal regulators were expecting the first release of the new software in 12 business days! The good news is that the team found out before the deadline date. The bad news is that the team found out only seven business days before the release signoff deadline. Also, the deadline date was during the monthly release moratorium period. So there’s that.

The decision

All was not completely hopeless, however. The regulators did not put a restriction on how much to release, just that there must be a release to show significant progress toward compliance. Prior to that, the team had been targeting a release in 6 weeks, based on the business value being delivered weighed against the cost of a software release. In particular, the first release carries significant one-time costs related to setting up environments, service IDs, users, etc. Obviously, most of those costs lost some importance balanced against non-compliance, so the team began preparations.

The first decision needed was what to do about the current iteration. The release requirement came on the third day of the iteration, so there were stories in-flight – some that were almost ready for demo. The Product Owner’s first reaction – and the correct one – was to declare an abnormal termination of the iteration.

“An abnormal termination is essentially blowing up the sprint and starting a new sprint instead. An abnormal termination is most frequently the result of a dramatic shift in business priorities – something previously considered important is no longer important, or something even more important is discovered.” – Mike Cohn, Making the Decision to Abnormally Terminate a Sprint

The Scrum Master gathered the team and the announcements were made: the iteration is over and immediate iteration planning must commence. The next important question was, “What will be in the release?” If this were a waterfall project, that would be difficult to answer. After just six weeks on a typical waterfall project, we could expect to have a draft of the requirements document. On an agile project, however, the goal is to deliver working software early and frequently in order to accelerate the feedback loop. Even though there were many tasks to be done before the software could be deployed to production, the code itself was potentially shippable at the end of each iteration. The only way this could be possible was by working with the Product Owner to create independent stories that deliver business value. In other words, the team could welcome the date change because they had good story slicing practices.

Splitting stories into small, vertical slices

Whether you are part of a waterfall or agile project, some high-level concepts remain the same:

• Goal is to deliver a quality product in a predictable, efficient and responsive manner;
• Activities – in some order and frequency – are to define, gather, analyze, design, code, test, release, maintain, and retire;
• Testing in a production-like environment prior to going live; and
• Decomposing the work into manageable components.

One of the biggest challenges for teams that are new to an agile approach is adopting a “vertical slice” approach. Teams aren’t used to thinking about decomposition this way, and there will be comments like “Our system is too complex”, or “We need to build really big features because end user training takes so long”. However, there is almost nothing that can’t be sliced into a story that delivers incremental business value.

In the second part of this article, I'll talk more about what I mean by vertical slicing and give some examples.

Sprint Planning (why we do it)

Why we meet

Dwight D. Eisenhower once said, “In preparation for battle I have always found that plans are useless, but planning is indispensable.”

The quotation seems to describe a contradiction with which all agile teams should get comfortable. On one hand, planning is critical to success. Planning allows us to organize and prepare for the future. On the other hand, when development starts, things can quickly change and the plan no longer applies. The fact that we go through a planning process increases the chances we will succeed, even if the resulting plan gets changed. This is why built-in feedback loops are so important in scrum.

There are too many meetings!

This comment from team members is common, but is (almost) never an indicator that the team is meeting too much. Scrum requires only a fifteen-minute meeting each day plus a half-day at the start and finish of each iteration (and frequently less than that!). Let’s examine some possible reasons that people feel like there are too many meetings.

First, the Scrum adoption started outside the teams. The teams have been told that they will do Scrum by corporate edict. A natural reaction to an order from above is to express annoyance at everything associated with that order.

Second, it is possible that Scrum ceremonies could look like a lot of meetings to a team that had no process at all. However, it is not likely that a team had been consistently delivering any work products if it had less process than Scrum.

Third, the perception of Scrum's overhead might stem from the cost of iterating every two weeks. The need to periodically drive the software to a shippable state feels like needless overhead to some individuals. On the other hand, most other processes lead to late products that miss on fully meeting business needs.

Fourth, people who believe Scrum is a lot of overhead may not fully understand it. They may see the new things they have to do (daily stand-up, iteration planning, iteration review, and retrospective). In the early stages, it is difficult to see the benefits of Scrum, such as greater visibility into progress, closer contact with users, as well as earlier coordination and greater communication with coworkers to ensure all team members are heading in the same direction.

Finally, if Scrum feels like it has too much overhead, it is probably being done incorrectly. When done right, Scrum is lightweight, management needs are small, and it doesn’t take much time away from coding. A perceptive Scrum Master will hear complaints as a warning signal and investigate to determine the true source of the problem. Luckily, it is entirely up to the team how effective a meeting will be.

Iteration planning

In Scrum, Iteration Planning is the meeting where the team defines the goals of the Sprint. In the first half, the Product Owner (PO) presents the priorities for the iteration and the team discusses each item. The team can ask the PO to clarify requirements and unpack any assumptions. The second half of the meeting (“planning”) is for the development team to discuss a high-level technical approach, identify the tasks involved in completing the stories, and commit to the stories they are accepting in the iteration backlog. At this point, the PO can choose to re-prioritize work to get the most business value based on team capacity. Everyone is expected to provide input and everyone’s voice is taken into account when determining the actual level of effort. This is the most intense of the Scrum ceremonies, but in a few hours, the team is ready to begin developing against the highest priority work.

When done correctly, iteration planning is an important factor in the success of the team:

• Whole team should be involved. If this is done as a team, there is buy-in and shared commitment for the work to be done during the iteration.
• Product Owner has insight into the technical aspects of what is involved. Even if they don’t understand the details, they gain an appreciation for the amount and complexity of the work to be done.
• Conversations should give substance to vaguely worded stories up-front, enabling developers to develop the right thing the first time.
• Everyone is communicating from the beginning. This sets the tone for the whole spirit of Agile/Scrum. Teams develop cohesion without barriers based on title or job descriptions.

Why "Quiet Agilist"?

I suppose the first question I need to answer, especially for myself, is why blog at all? Over the past two years, some transformational events have happened to me. Before you stop reading you should know that up until two weeks ago, the word "transformational" made my antennae go up too.

The first event was reading Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain. Finally! Someone understood that not only do I have something to say, but that in a per word comparison, what I have to say is probably more valuable than the average extrovert. Very empowering stuff! My first reaction was to tell my entire family that if they want to understand me (and many of the people they know) better, they should read the book. Their incentive to read it was a guaranteed, unlimited conversation about it with me anytime they wanted.

Of course, the second event was watching Susan Cain's TED talk. Not only was she articulating what I feel, she was demonstrating the power of her voice on a subject she is passionate about. Late in 2013, my sister (who took me up on my offer and read the book) invited me to join her at the Massachusetts Conference for Women which might seem an odd place for a dude to go, but Susan Cain was speaking so I was all-in.

Now, it is one thing to realize you can have a voice, it is quite another to know what to use your voice for. Enter Lyssa Adkins, Michael Spayd, and Michael Hamman. I attended their Agile Coach Bootcamp in Essex, Massachusetts in September 2014 and it was the experience of a lifetime. I had so much to say when I got home that my wife wondered if I had been replaced with a pod person.

Anyway, I am still finding my voice, but I have more clarity about my passion and I think my voice will emerge from that. In other words, I'm taking the agile approach to this blog. I know what I want, but the details are a little fuzzy, so I'll just start building it and the design will emerge through iterations. And...on those occasions when I do fail to find my voice, I plan to fail early so I don't waste your time. At least, that's the current plan.