Skip to content

Feed aggregator

Coping with a Fear of Inaccuracy

Agile Tools - Tom Perry - Thu, 09/25/2014 - 07:53

“Even imperfect answers can improve decision making.” – Donald Reinertson

When I read this from Reinertson’s book on flow, I realized that I had found the reason that people have so much trouble with story points. It’s a matter of overcoming their fear of inaccuracy. They are under the misguided belief in the accuracy of using hours or days to estimate work on projects. They’re basically afraid of being wrong (aren’t we all?) and that is the source of a lot of resistance to change. Being wrong sucks. I get that. Nevertheless, I’m wrong a lot.

Fortunately, wrong isn’t always boolean (unless you happen to step in front of a swiftly moving bus). There are shades of wrong. You can be just a little wrong, your aim just a little off, and still be headed in the right direction. Or you can be a lot wrong (the bus). That’s where frequently re-examining your decisions can help you catch the stuff that’s a lot wrong and fix it. What about the stuff that’s a little wrong? Don’t sweat it.

In the software world, a little wrong is still pretty useful. There is a tremendous amount of error and missing information. Compared to that, being slightly wrong isn’t so bad. Being slightly wrong gets you started – at least in mostly the right direction. You’re going to fine tune it anyway, so there’s really no need for decision making precision. That will come later, when you know more.

To me, the ability to overcome our fear of being wrong stems from an all-or-nothing mindset. We can’t allow ourselves to be even a little wrong for fear of failure. As Reinertson rightly points out, there is a time and a place for precision in decision making, but it’s not ALL the time.

Filed under: Agile, Process Tagged: error, estimation, Planning, sizing
Categories: Blogs

Reframing to Reduce Risk

Leading Agile - Wed, 09/24/2014 - 14:53

From what I have been able to decipher in my career businesses are around to make money. The way they make money is by offering goods and services to people willing to pay for them. Each business has their idea of the best way to deliver these goods and services they believe in some way sets them apart. Most businesses I have come across have come to settle on an approach that allows them to work on individual separately managed projects resulting in an increment of business value being delivered. Something similar to this:

  • Organize around projects
  • Present the work that needs to be done in “clearly defined” requirements
  • Staff the project appropriately according to the initial understanding of the scope and demand of the project
  • Work hard on this project until it is completed and delivered to the market

In my experience some risks for delivering these projects on time and on budget might be identified by a project manager early on in the initial inception phase of the project and might be reviewed at the end of each project, but not much attention is paid to the risks during the life of the project.

I understand that the following might not be a revolutionary brand new concept, but I wanted to work on exploring the intricacies of this idea with you while I continue to work through this myself.

Staying with a “Known Loser”

By not reassessing the risk throughout the life of the project we miss out on some great information to help us determine if the work can be completed on time (or at all for that matter) until the project is actually released.

We will continue to sink money into the project until it is “finished” even if everyone understands that there is no way to recoup our money through the sales of the eventual end result. I believe a big reason for staying with a “known loser” is that we become emotionally invested in these projects and stop looking at them objectively.

What if we were to stop looking at projects as work that needs to be done, and reframed them into a bucket of risk that needs to be removed.

Shifting Focus

By shifting the focus to reduce risk it allows us to have a different conversation about the work we are evaluating. If we are performing a lot of work without reducing our risk, we are simply pushing out the inevitable delay of a project thus causing us to spend even more money. However, if we were to focus on removing the risk associated with the funded work we can determine if it is still worth pursuing or if the money earmarked for this project would be better suited spent somewhere else.

I have recently begun to realize that the project progress drivers I used to focus on and track are actually not very helpful to measuring the likelihood of a project being completed on time.

Buckets of Risk

I believe that reframing our projects as a reduction in our exposed risk will allow us to focus our conversations on how valuable this investment is as opposed to how much money we might possibly make. If we continue this theory as we get more granular with the work and identify specific “buckets” of risk that are threatening to derail our progress we can more accurately predict if we will be able to deliver our work on time. The buckets I have used to date are Technical, Business, Verification & Validation, Organization and Dependencies. Let’s see some of the questions I’ve asked for each of these risk drivers and then you can decide if you think that these drivers will help you track the progress of your project.


  • Do we have the technology in house already?
  • Is this going to impact our current architecture?
  • Do we have the appropriate skill set for the needed technology?


  • Do we have clarity of scope?
  • Do we understand the target market?
  • Can we deliver on the intended business value?

Verification & Validation

  • Do we know how we are going to test this work?
  • Do we have sufficient information to be able to know when we should address this risk?


  • Are the teams that need to work on this risk stable and fully staffed?
  • Do we have the appropriate environments available to properly develop and test our work?


  • Is there anything that must be done outside of this team in order to deliver this work?
  • If there is work required by others, do we know their lead times?

Answering these questions will provide us the information necessary to truly understand our progress and make key decisions around the work we are evaluating.

The post Reframing to Reduce Risk appeared first on LeadingAgile.

Categories: Blogs

Tackle your organization impediments with 59 minute sprints!

Scrum Breakfast - Wed, 09/24/2014 - 12:48
As a comment on "How much do you let a new team self organize?" IanJ asked
Why are 59-Minute Scrums cool and what are they good for?The 59 Minute Scrum has been a popular training exercise for years in the Scrum community. The team gets a problem to solve, and goes through a "simulated" sprint to solve the problem. You get to experience real Scrum in a safe environment.

Fifty-nine minute sprints are an excellent learning tool because so much happens in such a short time. Everything that goes wrong in a real sprint can happen in a 59-minute sprint.  They are great for problem solving!

In my classes, I usually simulate a 3-day sprint, using 5 minutes for each half of the Sprint Planning and the Sprint Review, 12 minutes for each day, and 4 minutes for each daily scrum. If you add it up, it comes to 59 minutes. Each Scrum Team has a Scrum Master, a Development Team and a Task Board. Depending on the context, there may be one Product Owner for all the teams in the room, or each team gets it's own PO. Note the 59 minutes does not include the Retrospective, which I handle separately in my courses. I usually don't too much about the length of the Sprint Review either.

I have found that if a team does three of these over three days, by the end of third iteration, they are really good at the basics of Scrum and ready to do it "in real life."

What is the difference between this being a Scrum simulation and a real-life "micro Sprint"? Well not much, except for the importance of the results you are producing. If you plan to throw away the results, it's a simulation. If plan to use them, it's a micro-sprint.

What would be an example of using micro-sprints? One area is to address organizational impediments. Imagine you have assembled in one room not just the Development Team, but also their management, important stakeholders, the operations group and other interested parties for the product. Ask them, "What are the biggest impediments to success of our project?" Have them write them on stickies and post them on the wall. Like in a retrospective, have their owners present them. The others can ask clarifying questions.

Finally you do some sort of dot-voting to identify the top issues. Exactly how you do this depends on many things, most importantly the number of people in the room. One way is to each table create a short list of two or three items, merge the lists to get about 10 to 15 items, then have everyone dot vote the this short list to prioritize the problems.

Now you are ready to use Scrum 59's to tackle your challenges. What could you do to solve the issues identified? Form teams around the top priority cards, usually one team per card and one team per table (did I mention, island seating with about 6 to 8 people per group?) Whoever wrote the top priority cards becomes Product Owner for those cards.

Iterate once or twice to come up with possible solutions for those impediments.

I have seen awesome results with this approach! Usually the people who are most surprised are the managers in the room, because they have never seen their staff working so creatively and with such energy. And the teams come up with good ideas that the managers never would have thought of. Oh, and they get really good at the mechanics of Scrum and ready to take on the challenges of their project using Scrum to help them.

Prepare to be amazed! And don't forget you can start implementing those solutions right away!

Categories: Blogs

Spotify Engineering Culture (part 2)

Henrik Kniberg's blog - Wed, 09/24/2014 - 11:59
Here’s part 2 of the short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). Check out part 1 first if you haven’t already seen it! This is a journey in progress, not a journey completed, so the video is somewhere between “How Things Are Today” and “How We Want Things To Be”. Here’s the whole drawing: read more »
Categories: Blogs

On the road to high performance teams

Scrum Breakfast - Wed, 09/24/2014 - 11:49
I have been thinking about continuing education for Scrum Masters.

The objective of a Scrum Master is to create a high performance team, which is in turn part of a high performance organization. So both team and Scrum Master must develop their skills moving forward. Just facilitating the Scrum meetings won't get you there.

The Scrum Alliance has defined the Certified Scrum Professional (CSP) program. This is the journeyman-level Scrum certification (think Apprentice -- Journeyman -- Master ). This certification is not achieved by passing a test, but rather by demonstrating a commitment to Scrum by doing Scrum and learning about Scrum.

How do you achieve the continuing education needed to achieve journeyman status? My answer is the Scrum Breakfast Club. The Scrum Breakfast Club is an inexpensive, recurring open-space format for solving problems related to Scrum and Scrum Projects (and learning advanced Scrum as you do). You bring your problems and find solutions, with me and with other people who face similar challenges. I also provide an opportunity for one-on-one coaching during this time.

Each Scrum Breakfast Club workshop earns you four Scrum Education Units. (If you are familiar with the PMI, these are like PDUs, and can also be used as PDUs).

From a career point of view, if you take a CSM Certified Scrum Master course, follow it up with a CSPO Certified Scrum Product Owner course 6 months later, and participate regularly in the Breakfast Club, after 2 years, you will have accumulated enough Scrum Education Units to qualify as a Certified Scrum Professional. And you have had plenty of opportunities to address the actual issues in your organization.

Here is a description of the Scrum Breakfast Club. How does this fit into your plans?
Categories: Blogs

How Gilt Scales Agile

Scrum Expert - Wed, 09/24/2014 - 09:16
As Agile project management is being widely adopted, the questions of if and how it could scale is a main topic of discussion. In this blog post, Gilt explain how it scales Agile with teams, ingredients, initiatives and KPIs. The basis of the Gilt process is the initiative, which is a project that should be started in the coming 3 to 12 months. This is the “portfolio” vision for the company, but no roadmap is maintained. Gilt uses key performance indicators (KPIs) used to measure initiatives. Gilt is organized in teams ...
Categories: Communities

How to Slow Down Your Team (and Deliver Faster)

Agile Tools - Tom Perry - Wed, 09/24/2014 - 08:39

Is your team in need of a little improvement? Are they getting a little stale? Are you looking for a way to bring their performance “to the next level?” Well, maybe you should slow it down.

Oh I know, those other consultants will tell you that they can speed up your team. It’s the siren song of the wishful manager, “Speed my team up: faster!” But I’m here to tell you they’ve got it all wrong.

let me ask you this:

When you get a flat tire in your car, do you speed up? No! If there is a burning smell coming from the oven, do you heat it up? No! So if you see your teams start to slow down, why on earth would you try to make them go faster?

Let’s face it, when teams slow down there is usually a damn good reason. So rather than speeding up, perhaps it’s time to slow down, pull over, and take a look under the hood.

How do you slow down? Nobody really teaches that. Everybody is so focused on speeding up they seem to have forgotten how to slow down. Here are my top 10 ways to slow down your team (and hopefully address your problem):

  1. Apply a WIP Limit
  2. 1 piece flow
  3. A more rigorous definition of done
  4. Pair programming
  5. Promiscuous programming
  6. Continuous Integration
  7. Continuous Delivery
  8. Acceptance Test Driven Development
  9. Spend more time on impediments
  10. Hack the org

Taking time to implement any one of these things is almost guaranteed to slow you down. That’s a good thing, because your team probably needs to pull over to the side of the metaphorical road and repair a few things.

Filed under: Agile Tagged: improvement, slowing down
Categories: Blogs

Getting to Agile and the Coach’s Role

Coaching Agile Teams by Lyssa Adkins - Wed, 09/24/2014 - 00:00

Allison Pollard’s goal is “To Teach and Delight.” Her goal is to help people discover and develop their agile instincts. She enjoys mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. Allison blogs at over at To Teach and Delight.

After attending the Scrum Gathering in New Orleans, I’ve been pondering: What does it mean to be an agile coach?  I heard a few things that reminded me of a presentation my client created a few months ago; the presentation outlined the agile roadmap for the organization, and one of the slides was about the agile coach role up to that point.

Credit: Teddy Lambed

It showed cars in gridlock traffic, and one vehicle was labeled “agile coach.”  I’ll give you a hint what that vehicle looked like:

Photo by Steelman204

What does it mean for an agile coach to be an ambulance?  To me, it implies that there’s something critical going on and that the agile coach is urgently needed.  The team has injured themselves, and the coach is to come in and fix it.  There’s a sense of a right way and a wrong way, and the coach must apply the right techniques before running off to the next emergency.  And the agile coach is reactive rather than proactive.

The constant sirens and speeding through traffic and performing CPR on the scene…. being an ambulance is exhausting.

Let’s explore another perspective.  What if we think of the agile coach as a muscle car?

Photo by Abdullah AlBargan

Yeah… the coach has deep knowledge of agile and lean, so his engine is pretty powerful.  Some folks ooh and ahh at the agile coach for his expertise confidence.  They want to go for a ride with the coach and experience the power; others are afraid.  They scoff and stick to their sensible cars.  The muscle car could beat those cars in a race, but you’d have to get their interest first.  The muscle car coach is more proactive than an ambulance coach.  He can win over more people by dazzling them with agile knowledge and taking people for joy rides rather than emergency trips.  But if the coach is a muscle car, what does that make everyone else?

With that thought, I’ve been exploring a different perspective: agile coach as bumper car.

Photo by Glenn Beltz

If you’re on the track—coach, manager, team member, whoever—you’re in a bumper car. There’s movement and fun and spontaneity and safety on the track.  And it’s pretty much guaranteed: you will be bumped.  Everyone will be bumped—even the coach!  Every car is equal, and we are on the track together.  Everyone is safe and yet everyone will be pushed out of their comfort zone.  Most of all, there is laughter.

I am the bumper car that provokes movement.

This post originally appeared on Allison’s blog at To Teach and Delight on 5/17/2012.


Categories: Blogs

One Experimental Possibility: Self-Organization from Component Teams to Feature Teams

Johanna Rothman - Tue, 09/23/2014 - 13:24

If you are organized as platform team, middleware, and front-end teams, you have a  component team organization. That made sense at one point in your history. But if you are transitioning to agile or have transitioned, and if you want to use agile on a program, that might not make much sense now.

If you have a program,  you  have many people in your teams. Your platform team might not be 7 people, but several teams, maybe 50 people, if you are large enough for a program. Your middleware teams could be another 100 people, and your front-end teams could be another 100 people. You have lots of people and lots of teams.

I bet you do not have an even ratio of platform, middleware, and front-end teams. You have experts, here, there, and everywhere. And, if you are anything like my clients, you have trouble releasing features in an agile program.

What are the problems?

  • You have experts embedded in a wide variety of teams
  • The experts need to multitask to serve a variety of projects, so you incur a cost of delay to multitasking and queues
  • You are not releasing features. You have trouble when the components come together.

Even if the teams are agile, your program, the collection of projects is not agile.

What can you do?

You can ask the organization to try this as an experiment, for no longer than 2 weeks:

  • The only measure of success is running tested features. And, no one, especially no manager, gets to compare teams. This is an experiment that the organization is going to learn from. Some teams will have small and easy features. Some teams will not. This is not a competition. If you start comparing teams, the teams will game this measure and the organization will lose the learning. It’s not about the number of features. It’s about learning how to manage the stream of features through feature teams.
  • Ask three teams to volunteer: one platform, one middleware, and one front-end team. If more teams want to volunteer, fine. But you need three.
  • Those teams stop multitasking. Those teams agree on one ranked backlog among the three teams.  (I know, this might be the most difficult thing your organization has tried. I know you have experts. Ignore the fact you need experts everywhere. Agree on only one ranked backlog.)
  • Ask these three teams to self-organize as feature teams for now. No changing managers. No changing desks. They get to decide how to organize. If you are a manager, no decreeing who is a feature team with whom. Let the teams decide who is on what team. This works best in one large room. However, I have seen geographically distributed teams who were desperate to release a feature do this over distance.
  • Ask the Product Owner for these teams to make the stories as small as they can make them, preferably one or two team-days or less. This could be a huge challenge for the Product Owner. That’s okay. This is an experiment. I recommend a kanban board and limiting work in progress for this experiment.
  • Tell the teams that if they don’t have the expert they need for a story, that’s okay. They can pair, swarm, or mob together to get the story done. But, they are not allowed to interrupt another team.
  • The teams work on their backlog for this experiment (not any longer). They see what happens when everyone works in feature teams of their own making and no one multitasks, to get features to done. Remember, this is an experiment.
  • Retrospect at the end of this experiment so they can see what happened.
  • Decide what to do next. This is an experiment.

To sum: One self-organizing team, composed of platform, middleware, and front-end people. One backlog. One product owner. No longer than two weeks. Visualize the workflow. Limit work in progress. The only measure of success is running, tested features. No multitasking. Retrospect at the end. See what happens.

There are many things that can go wrong. But, there are many possibilities of learning here. This works best if the managers step back and don’t interfere. It works best with collocated teams. You can do this (and I have) with geographically distributed teams.

When I’ve facilitated this, the teams learn tons about how to work together and what they needed to do for their program. In several organizations, they wanted to do this again as an experiment.

Managers have to allow the teams to organize the way the product requires. Otherwise, you have Conway’s Law in spades.

When I have done this, I have had these results:

  • Most of the time, the teams were able to finish some of the features in their backlog without too much trouble. These features required some of the team to work together, either discussing the feature, or pairing.
  • They were able to finish most of the features in their backlog with a little trouble. These features required the entire team to work together.
  • Some of their features were too large to finish in the timebox.

These results don’t surprise me. I bet they don’t surprise you.

Every so often, teams have trouble finishing any features. They learned that they did not have sufficient expertise to do anything on their features in their backlog. One team spiked a feature for a day, swarming on it. They had more questions than when they started. They needed an expert who was in another team.

If you put the focus on releasing running, tested features, that is what people will do. But you have to focus on it.

Component teams aren’t bad, per se. But component teams don’t get you running, tested features. This is one possibility. Based on your experiment and reflection, you could try something else.

Categories: Blogs

Scaling Agile Your Way: Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS (Part 3 of 4)

The Agile Management Blog - VersionOne - Tue, 09/23/2014 - 13:07

In Part 1 of this four-part series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project developing a product or a solution has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.

In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (see Tables 1-4 of Part 1 of this blog series).  Each scaling agile parameter can assume one or more values from a range of values.   Each organization or a large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique.  However, “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise).  Systems thinking is important for Scaling Agile Your Way.

In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe), LeSS, DAD and MAXOS.  Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.   In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  SAFe and MAXOS represent radically different approaches to scaling agile. Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

Today, I will focus on the Sweet Spot, Challenge Zone and Unfit zone for SAFe and MAXOS:

Sweet Spot:

  • Indicates a good match between a scaling agile framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
  • Implementation becomes easier, more efficient and effective

Challenge Zone:

  • Indicates a challenging match between a framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
  • Requires more implementation effort compared to the Sweet Spot

Unfit Zone:

  • Indicates a poor match between a framework and a scaling agile parameter with a specific choice or range of choices for the parameter
  • Poor match could happen for one of two reasons:  (1) the parameter value chosen is not applicable, or (2) the parameter value chosen will not work well

Figure 1 illustrates the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presents similar information for MAXOS.  These are organized by the six scaling aspects mentioned above.  You will see four arrows in each Figure showing our recommendation for taking your large-scale agile projects closer to the Sweet Spot over a period of time.  I urge you to carefully review all of the information presented in Figures 1 and 2.  There is a lot of information, and it will take time to fully understand.  You may find it helpful to discuss with other agilists within your company.


Figure 1: Sweet Spot, Challenge Zone and Unfit Zone for SAFe


Figure 2: Sweet Spot, Challenge Zone and Unfit Zone for MAXOS

 From the information in Figures 1 and 2, it is clear that SAFe and MAXOS offer mostly distinct Sweet Spots, Challenge Zones and Unfit Zones, although occasionally there may be some overlap.  For example:

  • As shown in Figure 1, cross-functional, self-organized teams with co-located or close-by time zoned team members working under low to moderate governance structure offer a Sweet Spot for SAFe. But in Figure 2, self-organized, developer-centric (not cross-functional) teams of co-located members with minimal governance overhead offer a Sweet Spot for MAXOS.
  • In Figure 1, emerging user needs that must be discovered with sustained effort represent a Challenge Zone for SAFe; in Figure 2, the same scaling agile parameter value offers a Sweet Spot for MAXOS.
  • In Figure 1, low to moderate product modularity represents a Challenge Zone for SAFe, while Figure 2 shows that low modularity (tight integration of all code) creates an Unfit Zone for MAXOS.  On the other hand, a high degree of modularity in the product/solution architecture represents a Sweet Spot for both SAFe and MAXOS.
  • In Figure 2, heavy and rigid governance, or heavy/life-critical regulatory regime represent an Unfit Zone for MAXOS. But in Figure 1, the same scaling parameter values offer a Challenge Zone for SAFe.
  • In both of these, we see that, “Tightly coupled hardware product with embedded software and services (ex. appliances, cars, medical devices, smartphones, wearable computers, military gear, industrial equipment)” represent an Unfit Zone for both SAFe as well as MAXOS.

Get As Close to the Sweet Spot As Possible

If you decide to use SAFe in your enterprise (at least for some programs and portfolios), ideally you should try to get as close to the SAFe Sweet Spot as possible.  I have similar advice if you decide to use MAXOS (get as close to the MAXOS Sweet Spot as possible).  It is quite possible that your entire enterprise is not close to the Sweet Spot when you are just beginning your scaling agile transformation effort.  In that situation, I suggest starting with a scaling agile pilot program of 5 to 10 teams; after their initial education on SAFe (or MAXOS) is over, have this pilot program start as close to the Sweet Spot as possible.  This may require changes in some of your historical processes and practices, and development of SAFe (or MAXOS) with clear understanding and support for from your senior management.

For example, a pilot for SAFe may need to choose a relatively moderate domain complexity project, fairly modular architecture to minimize inter-team dependencies, co-located team members for most teams, a good deal of test automation and continuous integration (with prior training), a set of strong servant-leader ScrumMasters for each team, low to moderate governance overhead, low to moderate regulatory compliance regime, low to moderate impact of defects, etc.  See the Sweet Spot for SAFe in Figure 1.  If the pilot program teams are not close to the Sweet Spot yet, senior management will need to help them get there as the starting point for the pilot to make the scaling agile journey less painful.  With the experience of one release cycle underway, more pilot programs can be started close to the Sweet Spot; in fact, while the first pilot is going on, one to four more pilot programs can be identified and necessary effort expended to bring them close to the Sweet Spot as a starting point for their upcoming SAFe (or MAXOS) pilots.

Dealing With the Unfit Zone

The other extreme of the Sweet Spot is, of course, the Unfit Zone.  If a pilot team finds themselves in the Unfit Zone for at least one scaling agile aspect, the pilot will very likely fail.  For example, if a SAFe pilot program must use contributions from the open source community, or a MAXOS pilot program must operate under a rigid or heavy governance structure, or work under a life-critical regulatory regime, it will most likely fail.  Senior management must either take action to remove the issues creating the Unfit Zone, or select a different pilot program that does not find put the pilot in the Unfit Zone for any of the six scaling aspects.

Your Journey to the Sweet Spot is Your Tailored Journey

Your transition of your pilot program to the SAFe (or MAXOS) Sweet Spot will be your own customized plan and journey tailored to your situation.  You need to consider where these pilot teams are now, the gap between their current status and the Sweet Spot, and the effort and time needed to bring them closer to the Sweet Spot.  This effort will be dependent on each team’s situation, and is a very important aspect of “Scaling Agile Your Way.”  How do you take a pilot program close to the Sweet Spot is going to be your own unique journey and cannot be copied from a recipe book.  If a pilot program or a specific team within that program cannot reach the Sweet spot across all six scaling aspects, maybe it will come close to the Sweet Spot for four out of six scaling aspects, and stay in the Challenge Zone for the remaining two.  When a pilot program is in the Challenge Zone with respect a scaling aspect, it does not mean that the pilot program cannot start or proceed; but it does mean that you need to be prepared to spend more effort and overcome difficult challenges if you are going to operate in the Challenge Zone.

For example, if a pilot program has one or more teams with their members in different locations with widely different time zones, the SAFe Release Train Planning (two-day event required by SAFe) may involve a lot of complicated logistics and travel time/expenses for remote people, for which senior management support might be hard to come by (after all, “this is a pilot” is likely to be the argument).  If the pilot needs to operate under a traditional, hierarchical and rigid structure, it may create many organization impediments, complicating the challenges for the pilot program.

As shown in both Figures 1 and 2, your transition plan is to move as close to the Sweet Spot (the inner most rectangle area) as possible from the directions of Unfit Zone and Challenge Zone. This is illustrated by four broad arrows pointing toward the innermost rectangle in Figure 1 for SAFe and in Figure 2 for MAXOS.  If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The culprit is likely one of two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate its understanding and commitment to the success of scaling agile.

2.  Rooted in the market and business environment of your organization.  These reasons cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment the scaling agile framework practices with your own custom practices and retain the practices from the framework that are still applicable.

Table 11 below captures the Unfit Zone and Challenge Zone in its two rows, and the above two classes of reasons in its two columns.  The cells in this table illustrate specific examples of an action plan.

Table 11: Reasons and Actions for Unfit and Challenge Zonewith Examples


The transition from Unfit or Challenge Zone to Sweet Spot will require planned, disciplined and concerted effort — and a good understanding and true commitment from your senior management.  This journey will be uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but still have few areas in the Challenge Zone.

Customization Needs and Opportunities for Implementing Your Scaling Agile Framework

In addition to your unique and tailored journey toward the Sweet Spot of your scaling agile framework, a very important aspect of Scaling Agile Your Way is that each team, program or portfolio may need to implement key aspects of its framework in unique and customized ways.  It seems that the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be used to implement a variety of process modules of SAFe in customized ways.  Customization needs and opportunities for the MAXOS framework will come mostly in the context of implementing its advanced engineering practices of code contribution, automated testing, continuous integration, feature switches, continuous delivery, and making use of cloud computing facilities, etc.  I will elaborate on this topic in Part 4 of this series.

Are you about to start your scaling agile journey?  If so, do you have one or few pilot programs consisting of 5 to 10 teams in mind?  How do you feel getting them started closer to the Sweet Spot of SAFe, MAXOS or any other framework of your choice (such as LeSS or DAD)?   Have you run into the Unfit Zone for any scaling aspects?  I would love to hear from you either here or by email ( or on Twitter @smthatte.

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Part 4: Scaling Agile Your Way: How to develop and implement your custom approach

Categories: Companies

The Values of a New Methodology: Swarming

Agile Tools - Tom Perry - Tue, 09/23/2014 - 08:34


Perhaps the time has come for a new methodology. The old methodologies are showing their age as they are gradually incorporated and transformed by the large organizations of the world. There are many who feel that scrum today is but a pale shadow of what it used to be. One mediocre “transformation” after another has watered it down to functional irrelevance. Perhaps it’s inevitable that any method that you develop will eventually lose its vitality once it reaches the mainstream. Sooner or later you always sell out to The Man. That’s OK though, there is always a new young buck waiting to take up the mantle of The Next Great Development Process Breakthrough. What if it was Swarming?

If you were going to work on a team that used swarming as it’s only development process, what would it look like? This hypothetical team wouldn’t use any other processes, not scrum, not kanban, and certainly not waterfall – just swarming. It’s a pretty radical idea. Like many of the other methods, maybe we should start with the values. Values are the bedrock upon which we can build our new method. So what values would a swarming team have? Why don’t we start with these:

  • Passionate Engagement
  • Radical Transparency
  • Natural Rhythms
  • Simple Rules
  • Abundant Alternatives

That seems like a nice set of values, but what does it mean? Why would these be values that a swarming team would hold most essential? Let’s examine them each in turn:

Passionate Engagement – When you look at swarms in nature, from flocks of birds to nests of ants, one thing becomes apparent very quickly: each individual is completely and utterly focused on their task. Bees don’t simply ‘like’ honey. No, honey is much more important than that. To a bee, honey is life and death. Bees don’t ever take a coffee break. Similarly, we want teams that are equally passionate about what they are working on. We want them to believe that it is important, in fact it is absolutely the most important thing that they could be working on. Passion like that is infectious. Other people are attracted to it and soon you will find them working with you side by side just as passionate as you are.

Radical Transparency – Mobilize everyone to look for and manage team threats and opportunities. Share accountability, so that everyone can have the same responsibility for success and failure. All project information should always bet available at a glance on the walls, on dashboards, on my mobile phone, even at home. Access to information needs to be ubiquitous. Anywhere you look it can be found.

Natural Rhythms – A lot of the environments that we work in today don’t honor natural rhythms. Just ask anybody who works swing or night shift. On a swarming team, we want to make sure that we use the cadences of nature where ever possible. Our attention and focus have natural limits, so we can break up the day into smaller chunks. If we are happy and passionate about our work, does it really matter if its a Wednesday or a weekend? The norms of industrial society do not apply to a swarming team. They take their weekend whenever they feel like it.

Simple Rules – Use simple protocols to help enable the highest possible functionality of the team. We need to have simple rules of engagement that enable us to rapidly uncover disagreement and help us to promulgate learning as quickly as possible. Using simple rules requires conscious attention to their maintenance and upkeep. The team needs to keep their rules clear and disciplined in order for them to function well and not decay into disorder. Everyone in the flock needs to have the same signal for turning left.

Abundant Alternatives – Swarms thrive best in complex environments. There need to be an abundance of alternatives to explore, because that’s what swarms are really good at. When swarms find themselves in an environment characterized by scarcity, then they move on to more fertile ground. The same should apply to our teams, if they are working in an ecosystem that is rich with complexity, then they are probably well suited to it. If not, they move on.

These are what I would propose as values for a team using swarming as a development process. These ideas are what support and enable the kind of environment where swarming can happen. The tools are all there, we just need to be bold enough to use them.


Filed under: Agile, Process, Swarming Tagged: abundance, methods, nature, passion, radical transparency, rhythms, simple rules, Swarming, transparency
Categories: Blogs

Multikulti – vom Umgang mit Internationalität in Projekten

Scrum 4 You - Tue, 09/23/2014 - 07:35

Wir reden immer davon, dass es bei verteilten, global verstreuten Teams um das Verständnis geht, dass Amerikaner eine andere Kultur als die indischen Kollegen haben (Stichwort Skalierung). Es geht also immer darum, die unterschiedlichen Nationalitäten im Blick zu haben und deren Kultur zu verstehen. Bei meiner Arbeit mit internationalen Teams bin ich zu einer anderen Schlussfolgerung gelangt: Internationale Firmen haben selbst eine Kultur. Sicher, es gibt Einflüsse – Lokalkolorit. Aber die Kultur eines Unternehmens ist viel stärker als die des Landes.

Schaut man genau hin, dann sind die auftretenden Probleme oft nicht der unterschiedlichen Landeskultur zuzusprechen, sondern der Tatsache, dass sich zugekaufte Firmen nicht in den internationalen Konzern eingliedern lassen. Klar, Amerikaner ticken ein wenig anders als Deutsche - aber dass die Firma zugekauft wurde, eine andere Firma war, eine andere Art des Umgangs miteinander hatte, ist viel wichtiger und hat größeren Einfluss auf das Selbstverständnis des Einzelnen in einem Unternehmen als seine Nationalität.

Besonders deutlich wird das, wenn man Scrum in Hardware- oder Medizintechnik-Projekten einführt und cross-funktionale, multidisziplinäre Teams aufbauen will: Da bemerkt man plötzlich, dass nicht nur Tester und Entwickler in einer Abteilung unterschiedlich funktionieren, sondern dass es vollkommen andere Weisen gibt, die Welt wahrzunehmen. Wenn Ingenieure auf Biologen oder Chemiker treffen, wenn Metallfacharbeiter sich mit Elektrikern unterhalten sollen, wenn Grafiker sich mit Softwareentwicklern unterhalten, dann treffen die verschiedensten Weltbilder aufeinander.

Das wäre ja nicht weiter tragisch, wenn sich alle darüber im Klaren wären, entsprechend viel Zeit für den gemeinsamen Abgleich einplanen würden und das Management verstehen würde, dass es hier zu Konflikten kommen muss. Doch auch das Management hat natürlich seine blinden Flecken. Einige von ihnen waren vielleicht Ingenieure und sehen die Welt von ihrer Warte, andere sind Soziologen, Biologen oder Chemiker. Da wird oftmals gar nicht verstanden, was der andere meint oder warum er diesen und nicht jenen Zugang wählt.

Das alles sind lösbare Probleme und genau das ist die Aufgabe von ScrumMastern. Doch was passiert jetzt: Diese Teams sollen sich nicht nur aus unterschiedlichen Disziplinen, sondern auch noch aus unterschiedlichen Nationen an unterschiedlichen Standorten zusammensetzen. Vielleicht aus der Not heraus, weil es gar nicht anders geht. Nun wirken oft die Kräfte des Separatismus: Die Vertreter jeder Disziplin verstehen sich untereinander besser als mit den anderen. Sind diese auch noch verteilt, entsteht schnell ein Abwehrhaltung gegen die Kollegen am eigenen Standort, wenn dieser von einer anderen Disziplin ist und in der Minderheit. Oft nimmt man sich nicht die Zeit, sich wirklich kennenzulernen. Die ScrumMaster haben oft gar keine Chance – denn sie sind nicht vor Ort, sie steuern ihre Teams mit Hilfe von Tools und einem Video Conference Call. All das sind wirklich harte Bedingungen. Es wird noch schwerer werden, garantiert. Es wird immer öfter zu Konstellationen dieser Art kommen.

Doch eines wird sich durchsetzen: der Wille zu liefern. Der Druck auf Unternehmen, die so arbeiten (müssen), wird so hoch werden, dass sie sich etwas einfallen lassen werden. Sie werden Teams temporär zusammenziehen, sie werden wieder Menschen nahe zusammenbringen. Wenn Firmen wie Google und Facebook das können, wenn Apple in Cupertino ein Gebäude genau aus diesem Grund heraus baut, damit alle zusammen sind, dann sind diese Firmen schon längst wieder auf dem Weg, die Internationalisierung zugunsten der Produktivität zu reduzieren.

Die Voraussetzung dafür, dass dies gelingen kann: Eine gute Führung. Separatismus, das Auseinanderbrechen von Teams, kann sehr einfach verhindert werden – durch gute Führung. Durch eine Führung, die innerhalb des Teams, innerhalb der Abteilung und innerhalb der Firma die „gleiche“ Kultur schafft. Die gemeinsame Firmenkultur ist in der Lage, die Menschen zum Zusammenarbeiten zu bringen und Ungleichheiten vergessen zu machen. Die Aufgabe von Führungskräften wird schwerer werden. Scrum kann die Themen schneller ans Licht bringen. Lösen müssen es die Beteiligten zusammen.

Related posts:

  1. Effektiver mit Scrum | Hamburg |18.06. 20:00 | Lehmanns Fachbuchhandlung |
  2. Scrum – eine Revolution (1)
  3. Führung in Scrum | Manager | Teil 4

Categories: Blogs

Why Agile Game Development?

Agile Game Development - Mon, 09/22/2014 - 22:23
Agile is a set of values for building products, like games, more effectively by balancing planning with reality, delivering features and quality iteratively, while focusing on the emergent fun of the game by adding features and mechanics in a player-value prioritized way.  It allows a more responsive and predictable approach to development by balancing planning, art, design, technology and testing within small iterations rather than consigning much of the work in these areas to phases of development (i.e. big planning documents at the start and a flurry of testing and bug fixing at the end.  
Scrum is an agile framework with a further focus on the people making a game.  Scrum sets up a framework of small cross-discipline teams that take control of the work done in small iterations (2-3 weeks) to achieve a functional goal.  There are a number of reasons for doing this:
  • Small teams (5-9 people) communicate more effectively than larger groups.
  • Cross-discipline teams can respond to the needs of an emerging game (quality and functionality) more quickly.
  • Creative developers are more effective and motivated when they have a clear vision of a goal, can take ownership of their work and implement changes day-to-day without being micromanaged.
  • Scrum iterations level out workload to be consistent and sustainable throughout development.  They do that by balancing design, development, debugging and tuning so that the game doesn’t build an overwhelming debt of undone work that needs to be paid back, with interest, later in a project through death marches and compromises in quality.
Agile Game Development is a set of collected experiences of what works and what doesn’t work with iterative approaches and practices (e.g. Agile, Lean, Scrum, TDD, Kanban, etc) as applied to over a decade of game development with all genres and platforms.  Although it may not follow all practices of any single framework, it does adhere to the agile mindset and values.
Categories: Blogs

Design Thinking für Product Owner: Der Design-Thinking-Prozess

Scrum 4 You - Mon, 09/22/2014 - 07:45

Die drei wichtigen Komponenten des Design Thinkings sind das Team, der variable Raum und der Prozess. Der Design-Thinking-Prozess mag in dieser priorisierten Liste am Ende stehen, aber er ist das wohl bekannteste Element des Design Thinkings. Seine Struktur ist gut zu visualisieren und die meisten Menschen mögen klare Abfolgen, weil sie Sicherheit versprechen.

Offen und Unbekannt

Aber diese Sicherheit trügt: Die Sicherheit, die Product Owner und ScrumMaster aus dem Scrum Flow kennen, werden sie im Design Thinking nur ansatzweise wiederfinden. Der Design-Thinking-Prozess ist offener und die Ergebnisse sind unbekannt. Vielmehr ist der Design-Thinking-Prozess eine lockere Abfolge von Phasen mit jeweils einem ganzen Katalog an verschiedenen Techniken aus unterschiedlichen Disziplinen, die in der Kombination die Erfolgswahrscheinlichkeit bei der Entwicklung von Lösungen in komplexen Umfeldern erhöhen soll. Welche dieser “Vorschläge” das Team nutzt und wie lange es in den Phasen verweilt, entscheidet es selbst. Daher ist die Begleitung durch einen erfahrenen Design-Thinking-Coach sinnvoll, um nicht verloren zu gehen und stets fokussiert zu bleiben. Der Product Owner besetzt eine besondere Rolle: Zum einen profitiert er in besonderem Maße vom Design Thinking, da es hilft Produktideen zu entwickeln, zu testen und die Produktvision abzuleiten. Zum anderen ist er ein guter Wissensspeicher, um die gewonnenen Erkenntnisse aus dem Design Thinking in die Umsetzung mit Scrum zu überführen.

Zunächst die Lösungsmaschine aus …

Es gibt unterschiedlich detaillierte Varianten des Design-Thinking-Prozesses – allen gemein ist eine erste Hälfte, in der die Lösungsmaschine im Kopf abgeschaltet wird und der Fokus auf der Nutzerperspektive und auf dem Verstehen, Beobachten und Analysieren der Bedürfnisse des Nutzers liegt.

… und dann die Lösungsmaschine wieder an.

In der zweiten Hälfte wird nachgedacht, wie erkannte Probleme und Bedürfnisse gelöst und bedient werden können. Nach der Ideenfindung werden die kritischen Funktionen der erdachten Lösungen isoliert und mit Prototypen am Nutzer getestet. Mit dem so generierten Feedback kann in eine beliebige vorherige Phase des Prozesses eingestiegen werden, um die Lösung dicht am Nutzer entlang zu optimieren oder komplett zu verwerfen und mit dem neuen Wissen andere Ideen zu generieren.

Der detaillierte Design-Thinking-Prozess

Wir betrachten den Design-Thinking-Prozess so wie er an der HPI School of Design Thinking gelehrt wird. Diese Variante ist in 6 Phasen geteilt und gut zu verstehen:

Design Thinking & Change Management Flipcharts

Vorbereitung der Design-Challenge

Bevor der Prozess startet, müssen die Teammitglieder gefunden (siehe Teil 2: Das Design-Thinking-Team), der Raum bereitgestellt (siehe Teil 3: Der Design-Thinking-Raum) und die Design-Challenge (zu lösende Aufgabe/Innovationsauftrag) formuliert werden. Die Challenge soll dabei eine Richtung vorgeben, aber nicht einschränkend wirken. Beispielsweise ist die Formulierung “Finde neue Wege, Speiseeis online zu verkaufen!” sehr eng, da es gut sein kann, dass der Onlinevertrieb und das Nutzerbedürfnis nicht zusammenpassen. In dem Fall würde lediglich eine inkrementelle Verbesserung erarbeitet oder aber ein mutiges Team würde die Aufgabe reformulieren, um eine wirkliche Innovation zu kreieren.
Offener wäre: “Finde neue Wege, Speiseeis zu vertreiben!” Hierbei kann das Design-Thinking-Team auch die Möglichkeit eines Onlinevertriebs prüfen, ist aber nicht von Anfang an darauf fokussiert.

Stellen wir den Innovationsauftrag noch positiver und bedürfnisbezogener auf: “Wie können wir den Genuss von Speiseeis zu Hause verbessern?” Nun haben wir die Richtung und den Rahmen definiert, es geht um Genuss und das Bedürfnis zu genießen. Die Angabe “zu Hause” bedeutet, dass das Eis irgendwie dort hinkommen muss und gleichzeitig, dass private Situationen beleuchtet werden müssen, in denen Eis genossen wird. Wir können nun beginnen, ein Erlebnis zu kreieren.

1) Verstehen

In der ersten Phase tauschen sich die Teammitglieder aus. Durch das Teilen des vorhandenen Wissens in der Gruppe synchronisiert sich das Team, Rückfragen zur Design-Challenge können gestellt werden und alle Teilnehmer werden zu “Sofortexperten”. Das Team entwickelt ein Gespür für die Wissenslücken, die es im nächsten Schritt mit Hilfe von Recherche und realen Nutzen füllen möchte.

2) Empathie (Beobachten, Erforschen)

In der zweiten Phase geht es darum, den Nutzer zu verstehen und Empathie aufzubauen. Die drei bekanntesten Mittel sind offene Fragen (Interviews), Beobachten (Observation) und sich selbst in die Lage des Nutzers bringen (Experience).

3) Synthese (Sichtweise definieren)

Nach der Analyse werden die Massen an Informationen gebündelt, sortiert, verdichtet, ausgewertet und priorisiert. Oft haben sich die Teams in der vorangegangenen Phase in kleinere Gruppen geteilt. Nun wird mittels Storytelling die Information geteilt und im gesamten Team bearbeitet. Informationen werden auf Haftnotizen gemalt, möglichst visuell mit wenig Text, um Fotos und mitgebrachte Artefakte ergänzt und mit unterschiedlichen Tools verarbeitet: z.B. Personas, Zeitachsen, User Journeys, 2×2 Matrix, Venn-Diagramm und einige mehr.

Dies alles wird in der Sichtweise (POV – Point of View) zusammengefasst: Diese besteht aus der Definition des Nutzers, seinen Bedürfnissen und besonderen Einsichten aus der Recherche. Davon abgeleitet werden nun unterschiedliche Fragen nach dem Muster: “Wie können wir <Nutzer> helfen… <Ziel> zu erreichen… und <Bedürfnis> berücksichtigen?”

4) Ideenfindung (Ideation)

Mit den Fragen aus der vorangegangenen Phase darf endlich die Lösungsmaschine im Gehirn wieder aktiviert werden. Meist werden klassische Brainstorming-Techniken eingesetzt. Wichtig ist, dass schnell und viel produziert wird: Kritik ist verboten, verrückte Ideen sind willkommen, es soll auf den Ideen anderer aufgebaut werden und natürlich wird im Stehen gearbeitet. Wenn die Ideenfindung ins Stocken gerät, helfen Anregungen wie: “Was würde Superman tun?” oder “Was müssten wir tun, um den Erfolg auf jeden Fall zu verhindern?”
Nach dieser Phase werden Ideen nach Extremen geclustert: Was sind die hilfreichsten Ideen für den Nutzer? Welche Ideen lassen sich am schnellsten umsetzen? Welche Ideen sind am radikalsten? Welche Ideen finden wir einfach gut? Eine oder mehrere Ideen werden aus diesem Ideenspeicher für schnelle Tests ausgewählt.

5) Prototyping (denken mit den Händen)

Ideen werden nicht diskutiert, denn nicht das Team entscheidet, was erfolgversprechend ist, sondern der Nutzer! Dazu müssen die Ideen erlebbar werden. Prototypen zeigen die gesamte Idee oder einzelne kritische Funktionen davon. Es werden kleine LEGO Welten gebaut, Plakate entworfen, Rollenspiele aufgeführt, Klickstrecken produziert, Objekte erschaffen, Filme gedreht… der Phantasie sind kaum Grenzen gesetzt, um innovative Produkte und Dienstleistungen greifbar zu machen. Wichtig ist allein, dass wenig diskutiert, sondern einfach gebaut wird und die Prototypen einen improvisierten und unfertigen Eindruck machen, um im nächsten Schritt ehrliches Feedback zu erhalten, das sich auf die Funktionalität und nicht auf die Ästhetik bezieht. Außerdem wird das Team einen Prototypen, der wenig Aufwand gekostet hat, auch leichter wieder fallen lassen.

6) Test

Das Team hat beim Erstellen der Prototypen bereits die Nutzerperspektive eingebracht und somit auch erste Tests vollzogen. Nun erfolgt aber der nächste Kontakt zum realen Nutzer. Dieser soll so viel wie möglich ausprobieren und verstehen, aber bitte keine langatmigen Erklärungen! Nur beobachten und fragen, jeder kritische Blick und jedes “Aha” hilft die Idee zu verbessern.


Mit dem Feedback aus den Tests steigt das Design-Thinking Team in eine passende vorangegangene Phase wieder ein. Wird die Idee komplett verworfen, bietet sich eine neue Recherche mit dem gewonnen Wissen oder eine andere Idee aus dem Ideenspeicher an. War ein Prototyp erfolgreich, kann dieser mit einer darauf aufbauenden Ideenfindung in eine noch passendere Lösung verwandelt werden.
Oft wird so der Design-Thinking Prozess zwei bis vier Mal durchlaufen, bis am Ende eine wünschenswerte, machbare und wirtschaftlich tragfähige Lösung steht.


Das Wissen wird übergeben. Produkte müssen hergestellt, Software programmiert und Dienstleistungen und Prozesse umgesetzt werden. Und das ist nun nicht mehr die Aufgabe von Design Thinking.

Related posts:

  1. Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?
  2. Produktfindung mit Design Thinking
  3. Design Thinking für Product Owner – Teil 3: Der Design-Thinking-Raum

Categories: Blogs

From Bankruptcy to Abundance

Agile Tools - Tom Perry - Mon, 09/22/2014 - 04:58


I recently read Rose and Benjamin Zander’s book The Art of Possibility: Transforming Professional and Personal Life and I strongly recommend it. To me it was a book full of stories about mindset management, all primarily set in the wonderful context of music. Much of the book described techniques for moving from a mindset of bankruptcy to a mindset of abundance.

That’s something that I can relate to in my current role. There are times when I find myself trapped in that mindset of bankruptcy. The narrative in my head goes something like this: None of the teams I work with is doing what I hoped they would. We’re not agile enough. We’re not innovative enough. Our culture is all wrong. We can’t get there from here. We suck.

That’s the mindset of bankruptcy talking. There’s never enough. We’re never good enough. It’s a pretty bleak place. I know I’m not alone in living there from time to time. I work with people who come to me with this narrative all the time. What do I tell them?

Well, first of all, I have to check in with myself and see where I’m at. If I’m in the same place as they are, then this conversation isn’t likely to go well. The best I can usually do in that case is to commiserate with them.

But there are times when you are in the place abundance. There is another perspective that allows a much different interpretation for the same set of circumstances. I find that talking with folks from a variety of different backgrounds helps. They’re the ones who will look at me and say, “Wow! You guys are awesome! I hope we can get there one day!” At first my reaction is to deny what they are saying. We aren’t that good. You don’t really get it. But then sooner or later it dawns on me that although we have many things to improve on, we also have managed to achieve amazing things along the way. Things that we now take for granted.

The difference between those two mindsets is that one has room for new opportunity and the other leaves little room for any opportunity at all. I loved their expression when something fails, “How fascinating!” Using a phrase like that suggests curiosity and an openness to exploration. I love it.

I don’t know if I have the kind of temperament that would enable me to live in this mindset full time. But I sure would like to visit it more often and maybe even share the trip with a friend.

Filed under: Agile, Teams Tagged: abundance, Agile, attitude, bankruptcy, management, mindset, perspective
Categories: Blogs

The Danger of Point Solutions

NetObjectives - Sun, 09/21/2014 - 14:58
The software development world has created several approaches to improving the work at the team level. These include eXtreme Programming, Scrum, Kanban, Kanban Method. While all of these solutions are based on some degree of reality, much of their organization and practices are based on the belief systems of their creators. I think we can get the best of what these all contribute not merely by...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Release Planes versus Release Trains

Leading Agile - Sun, 09/21/2014 - 11:49

There is a lot of talk these days about SAFe.  I have a lot of respect for what Dean Leffingwell has done but there is a minor use of language that has been bugging me in recent days. Just as I disagree in using farm animals to describe people on a Scrum team, I believe the Release Train metaphor is dated and has its limitations. I believe, when doing Agile at scale, a Release (Jet) Plane offers a better representation of the complexity of enterprise level delivery processes.

When I think of a train, I think Amtrak in the NorthEast Corridor, the DC Metro, or School House Rock.  I don’t think of a train when thinking of the most modern or efficient mode of transportation. So, why pick the train?

I get the metaphor:

  • The train departs the station and arrives at the next destination on a reliable schedule.
  • All “cargo,” including code, documentation, etc., goes on the train.
  • Most people needed on the train are dedicated to the train.

When speaking to architecture, SAFe refers to architectural runway, not architectural train tracks or a rail-yard.  It’s a mixed use of transportation metaphors that is not explained.  The runway is a perfect alignment with my Release Plane metaphor.

  • Most people needed on the plane are dedicated to the plane.  Sure, each plane has a flight crew but they also have a ground crew at each airport (DevOps).
  • All “cargo,” including code, documentation, etc., goes on the plane.  I also recognize that some cargo is more valuable than others. Let’s put them in first class or allow early boarding.
  • Planes depart airports and arrive at the next destination on a reliable schedule, unless you fly American Airlines.

A few more comparisons:

  • When you go to the airport and try to get you and your luggage on a plane, don’t you and your luggage (the cargo) go through a series of checkpoints?
  • If you don’t get past a checkpoint, do you still think you’re going to get on the plane? This should be pointed out.
  • Doesn’t everyone have to comply with cargo size limitations?  Again, this should be pointed out.

None of these additional comparisons apply to the release train metaphor as well as the release plane.

I just thought I would bring this up.  Can you think of any other things that would apply to my plane metaphor?  Maybe we’ll see the release plane used in SAFe 4.0.

The post Release Planes versus Release Trains appeared first on LeadingAgile.

Categories: Blogs

Building the Corporate User Interface

Agile Tools - Tom Perry - Sun, 09/21/2014 - 07:47


A while back I did a talk on the subject of “Hacking the Organization”. It was largely inspired by Jim McCarthy’s talk at a local Open Space. Listening to his talk I realized that people who have programming skills AND insight into processes have a unique opportunity to reprogram the organizations that they work in. This reprogramming can be done in a few different fashions:

Changing the processes: Changing the way people work by introducing new methods, practices and protocols

Changing the systems: integrating the systems to make reporting, operations, and other business processes work more smoothly

Blending the processes and the systems: Changing the way people work and the systems that they work with so that they support each other – making people more alive and engaged in the organization. It’s merging the people and the machine to enhance each other.

In fact, in the lean/agile community, we have become very adept at creating relatively high functioning teams using practices that have evolved significantly over the last few decades. Technology has evolved at an even faster rate, with the web, mobile and other technologies creating opportunities for collaboration that never existed just a few short years ago. Modern teams have the opportunity to revolutionize the way people and systems work together.

Those of us who can code and who are interested in improving the process to benefit everyone are the magicians who have a uniquely powerful opportunity to create real change in organizations. That’s not a bad thesis, right?

Well, the more I thought about it, the more I realized that we are not simply trying to change the organization for the pure sake of change. We strive to make the organization more “user friendly”. Our changes aim to make the organization into a place where people can express their work as joy and express passion for what they do. It should enable that sort of engagement, which forms the catalyst for genuine innovation and products that people love.

What would an organization with a good user interface look like? That’s easy:

  • It’s fun to use
  • It has functions we care about and are easy to find
  • We can clearly see how to do what we need to
  • When we take action it is effortless and feels natural
  • It’s responsive, giving users rapid feedback to their actions

What could we do as organizational hackers to achieve these ends? We could introduce ramification to corporate operations. Turn in your timecard promptly and level up! Create electronic systems that make it easier to reward or thank our peers for their work. We could create dashboards that provide visualizations for corporate operations. We can make this information universally available, even omnipresent for everyone in the company from the CEO to the janitor. We can make our work visible so that people can make educated decisions about what the most important work is that they can be doing. All corporate activities should be self serve and provide immediate feedback.

Wouldn’t that be awesome?

We can do that. We don’t have to ask for permission, we can just do it. Link the sales reporting system to a dashboard. Go ahead, do it. Pull in some transaction metrics and do a little simple math to demonstrate the average dollars per transaction. Automate the HR system so that with the press of a single button you can initiate hiring someone – automate all the paperwork. You make the work easier for everyone. You not only save yourself time, but you save time for everyone else who does that work now – from now on! This kind of savings can multiply very quickly.

The coding really isn’t that hard – most back office systems have pretty sophisticated APIs that enable the possibility of this kind integration. All it takes is someone with the will to make it happen. Guess who that is? You.

Filed under: Agile Tagged: Agile, back office, core protocols, hacking, integration, organization
Categories: Blogs

Enough With Defending Approaches

NetObjectives - Sat, 09/20/2014 - 19:14
My banter on twitter about being unhappy with Scrum and the Kanban Method leaving things out is reasonably well known.  I very often exclaim that Scrum should be done within the context of lean (a 10+ year old rant) and that the Kanban Method must attend to teams (which it’s been deemed to be orthogonal too).  When I make my claims I usually hear that “these approaches are designed this way”....

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Recommendations for Kanban Coaching Professional Masterclass

David J. Anderson & Associates - Sat, 09/20/2014 - 15:55

Recent attendees of the Masterclass tell you what they valued and why you should attend...

David's approach to training is truly unique. I now have a different lens to view my team's upstream work, current work in progress, and deeper knowledge on how to communicate risk without disrupting the flow of changes throughout the organization.  What David has created with his, Modern Management Framework, is a revolutionary way of thinking for an evolutionary way of change. Jay Paulson


read more

Categories: Companies

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.