April 21, 2014

Agile Coaching Blog

Agile Coaching Blog

This agile coaching blog has news & articles from BigVisible coaches and trainers. Find agile topics like Scrum and Kanban. Read about collaboration, communication, & enterprise agile. See hints for better daily meetings, retrospectives, and Scrum reviews. Learn about leading edge tools for lean startup and customer development. Discover information geared toward agile teams as well as leaders & executives.

We hope the information you find here will help your organization become more agile, adaptive, and innovative. Our goal is to help you delight your customers & succeed beautifully.

What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Scrum Meeting Success for Distributed Teams

In a previous blog, I discussed ways to make distributed daily scrum meetings more effective. This blog reinforces those ideas and provides additional tips to run successful scrum meetings with geographically distributed teams.

Productive, timely, 15-minute Daily Scrum meetings, remain a challenge. As many practitioners will attest, co-located Daily Scrum meetings are nearly as challenging for some of the same reasons:
- Meetings go beyond 15 minutes
- Not everyone has a chance to be heard
- Conversations wander into resolutions and opinion
- Impediments are not captured and addressed
- Others interrupt
And more…

Holding team meetings where members are not in the same physical or mental space is quite challenging, and it becomes more so when the team is geographically distributed. As I mentioned previously, the initial rule of thumb was to breakdown the daily meeting into small deliverables and then focus on each part of the meeting. The overall Definition of Done is the teams take ownership of the Daily Scrum meeting and use this as a foundation/basis. This idea has evolved into a goal for Daily Scrum meetings of having the team take ownership and management of their daily meeting. With this, we can create “Definitions of Done” for each part of the meeting.

For example:
Part 1: The team listens to each other’s ‘questions 3’ with no interruptions.
- Definition of Done: each team member has an equal voice to state their answers and be heard by their team members.

Part 2: The ScrumMaster reads the impediments/issues they recorded and the team adds, corrects and confirms the list is correct
- Definition of Done: the ScrumMaster reads off the impediments and has the team approve them

Part 3: The participants in the Daily Scrum meeting organize additional conversations around the Sprint and the results of the Daily Scrum Meeting the team.
- Definition of Done: the team members self-organize and work on the issues at hand and have these groups communicate what they did before the next scrum meeting, to the rest of the team.

When it comes to implementation there‘s a way to execute this process. For example:.
The meeting begins with one team member (initially the ScrumMaster) asking a team member the ‘questions 3’.
- The team member identifies the task and the story they are working on. They describe at a high level what they are doing and how much more time they need to finish.
- The team member then describes what they plan on doing tomorrow. If they will be moving to a new task, they should state which task.
- The team member then states what issues/impediments/ concerns they have about getting the work done or completing the sprint..
- Team member #1 then asks another team member the ‘questions 3’. This is a sure way to transfer ownership of the meeting to the team.

This is not a ritual. It is a basic pattern of action that can be used to start off a new team, orient new team members and get a team back into a rhythm. I have found that getting back on track is a lot easier if there is a simple base or foundation to structure and define roles. From there, teams can quickly self-organize…and it works well when things get stressful!

Roles and Actions for the Daily Scrum
ScrumMasters don’t run the Daily Scrum – they guide the team to run it themselves. Their primary focus is to collect the impediment list and get it approved by the Team. There should be a task on the task board regarding impediments for reporting the status of impediments.

Team Members individually and collectively run the meeting.

The Product Owner should be there listening and ready to answer questions immediately after the meeting closes.

Anyone who has committed to deliver something to the team during the Sprint must have a task on the task board and attend and answer the questions 3. This includes Product Owners, stakeholders, and management.

Guidelines and Techniques for the Daily Scrum
1) Turn the meeting ownership over to the team by having each team member ask another member the ‘questions 3’. Since there is no pattern or set order when one team member asks another, people on phones pay attention because they do not know when the questions will come their way.

2) The ScrumMaster is the servant leader, helping the team stay focused on the conversation, the task board, and the questions. It’s surprising how quickly the rest of the team picks up on this focus and brings the more loquacious and “off tangent” teammates back on track by asking “what task are you talking about?” Some teams go as far as including a protocol statement in their team charter stating all questions in the daily Scrum meeting begin with the user story and the task.

3) At the end of the first part of the meeting, the ScrumMaster, who may have been taking notes on the impediments, begins the second portion of the meeting by going over the impediment list to see if any were missed. This action reinforces that this meeting is for the team and that all issues are visible and noted.

4) The third and final part is a call for the issues to be discussed immediately after the meeting. Any team member, including the Product Owner may ask for conversations on story or task issues.

5) As soon as that is sorted out, the ScrumMaster requests that all decisions resulting from the upcoming conversations be communicated before the next daily meeting.

6) The daily meeting is closed and the conversations continue.

Share:

Video: Thoughts On Agile Design with Dave Gray and Alan Dayley!

Gamestorming is one of the foundational books on interactive and highly collaborative meetings. Dave Gray, one of the book’s authors, has begun working on a new book titled “Agile Design Principles.” He is interviewing various people who work and write about Agile ways of working. I was pleased to be interviewed.

Our discussion ranged fairly wide, as you can see from the topic list below the video. Enjoy!

  • 0:01:00 – What does Agile Design mean?
  • 0:03:38 – The utility of “open plan” offices and what makes them work or fail
  • 0:09:30 – Teams should control how they work
  • 0:10:13 – Good interruptions vs. bad interruptions
  • 0:12:58 – Working before Agile and getting to it
  • 0:14:55 – Technical debt can be the spur to change
  • 0:18:38 – W. Edwards Deming and seeing “the system” when software is ephemeral
  • 0:21:58 – Distributed teams can work by paying attention to communication
  • 0:24:01 – The social part of Agile and how it helps
  • 0:26:04 – Division of labor is not necessarily as good as we think
  • 0:30:52 – Teams of teams keeping coordinated with Product Walls
  • 0:38:30 – Leadership gives the place to start, the framework to catalyze self-organization
  • 0:39:30 – What Agile and self-organization means for managers
  • 0:42:35 – Common obstacles to transitioning to Agile ways of working
  • 0:47:32 – Capacity in full-time equivalent hours vs. empirical measure of capacity
  • 0:52:05 – Definition of Done
  • 0:53:39 – Is there a “no excuses rule” in Agile?
  • 0:56:38 – Empowerment vs. power
  • 0:58:45 – Going back to Deming, the “system” of sports teams and hero experts
  • 1:02:40 – Create a culture of safety and trust in order to innovate

I enjoyed talking with Dave and I hope you can gain some tips and insights from our conversation.

Want more Alan Dayley in your life? Dive in.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Strong Teams: The Foundation of Scaled Agile Success

Agile at scale is BigVisible’s specialty. Our coaches have been developing and refining practices for scaling agile methodologies in large enterprises for over a decade. The “BV Way” was developed as BigVisible’s approach to implementation at scale. Recently other scaling frameworks have emerged and are gaining tremendous interest in large enterprises.

The current market-leader among these enterprise scaling models is the Scaled Agile Framework (SAFe). BigVisible has embraced SAFe and hybrid solutions that incorporate SAFe and elements of other scaling models, along with our BV Way.

Each approach has its strengths and weaknesses, but any scaling of agile to large programs and portfolios must be built on a firm foundation of team practices that support scale and complexity.

As the agile adoption curve has progressed to the point that many mainstream organizations have experienced benefits using Agile at the team-level, many now want to multiply those benefits by using agile practices to manage large programs and product suites involving many teams. Some are moving to “agile-ize” their steering and portfolio functions across dozens or hundreds of projects or products.

At this juncture, organizations trying to use agile methods at scale, usually find themselves grappling with substantial additional complexity related to planning and rolling up or consolidating information at higher levels of planning and tracking. Often early attempts are troubled by poor transparency of organizational capacity at different levels, which leads to high levels of variability in forecasting (a fancy way of saying their plans are inaccurate).

In conversations with clients and prospective clients, we often find they are eager to scale agile at the program and portfolio levels before they have reached even modest levels of proficiency in technical and project management practices for delivery execution at the team level. Some think their teams are doing Scrum pretty well, others think that introducing program and portfolio level planning structures will somehow strengthen their teams’ weak execution, from the top down. This is a dangerous misconception, analogous to thinking that adding additional floors to a tottering building will somehow strengthen its weak foundation.

When I was VP of Professional Services at Rally, we developed a model for maturing an organization’s Agile capabilities. The “Flow, Pull, Innovate” model nicely illustrates the importance of establishing foundational delivery capabilities at the team level before adding scale and complexity:

Slide1
- Rally Software

BigVisible’s “BV Way” similarly ensures that the critical base factors of software production, the development teams, are demonstrably in control BEFORE we expect program and portfolio planning functions to be predictable and managed.

Businesses need to make intelligent tradeoff decisions for scarce development recourses. To do this they need reliable data that is accumulated from observations of historical performance. This historical data populates a statistical model that supports higher-level plans, larger organizational structures, and longer time horizons through the aggregation of data.

To forecast accurately, our base-element statistics must provide sufficient data points of low standard deviation. Our confidence in the predictive utility of our data, its accuracy and precision, should be known and communicated transparently. Rolling up weak stats with high variability and/or artificially high precision will inspire false confidence. Both are damaging to the delivery organization’s credibility, morale, and the agile brand in the organization.

Assuming there’s a consensus that it’s bad to rely on a complex structure built on a foundation of marshmallows, what are some key traits and behaviors demonstrated by agile delivery teams that do provide a solid foundation for scaling?

Here are some specific indicators of Delivery Team maturity:

    1. Measures of velocity, throughput, and/or cycle time: If these stats aren’t tracked, you can’t know the team’s capacity and you can’t forecast. If the data varies widely (high standard deviation) the team’s capacity estimates inspire low confidence, and they probably have underlying issues that contribute variability and risk. These stats can be gamed, so ensure process disciplines are adhered to (eg: accepting only done stories of productizeable increments).

    2. Short cycle times with high fidelity feedback: Longer cycle times and larger batches yield infrequent feedback/sampling rates and mask variability. Relatively more data points should be provided if cycle times are long (4 week iterations, for example).

    3. Consistently high acceptance rates: Teams should consistently deliver by the end of the iteration what they committed to in the beginning. If the percentage of story points accepted over those committed (plus pulled in), is consistently >90%, for example, it indicates several positive behaviors and capabilities are probably present: the team understands their work, their relative estimates of PBIs are consistent, they swarm to complete stories and limit work in progress. Teams with low acceptance rates tend to generate highly variable velocities.

    4. Thorough Definition of Done (D of D): High acceptance rates don’t mean much if we accept software that isn’t fully validated and integrated, or produce software that may not deploy predictably. A Definition of Done that allows acceptance of anything less than a potentially shippable increment creates batches of risk and introduces variability near release time.

    5. Comprehensive test strategy and continuous delivery: It is critical to fast feedback that every code change initiates progressive stages of high-coverage automated test suites in a continuous delivery pipeline. Even if not releasing to production, demonstrating the capability offers assurance that code assets integrate and deliver value predictably. No pipeline promotion step (except maybe a “DEPLOY TO PROD” button) should be vulnerable to human frailties. Software that relies on humans to read or remember or type to build, test, deploy, configure, migrate (or whatever), will suffer exponentially greater variability when scaled to larger programs.

    6. Measured and managed technical-debt: High levels of technical debt are often related to a weak D of D, or it may simply be the fruit of sins past. Technical-debt increases variability and risk. Technical debt includes untested code, code lacking automated test coverage, unmerged code, unintegrated system components, design flaws, and code smells that require refactoring. The lack of enabling infrastructure can also be considered a form of debt or underinvestment.

    7. A well-groomed backlog: We generally advise teams and Product Owners to maintain 1.5 to 2.5 iterations of “ready” stories in the backlog (maybe more going into release planning). Well-groomed and ready means more than story cards with estimates. It means ready to code- acceptance criteria everyone on the team really understands, and a viable high-level design approach everyone has an informed consensus on.

    8. Continuous planning at all 5 levels: Agile planning at 5 levels suggests an appropriate level of granularity for work items at each time horizon. How many teams have you seen who do standups and sprint planning, and think that’s sufficient to kick scrum butt? Without a roadmap and vision, and a release plan to map strategy to tactical execution, a team is operating myopically with too short a planning horizon. They will fail to address risks, architecture, and design in a timely way (through dialog, spikes, reference implementation, UI guidelines, feature tests/experiments, etc). These teams will fail to provide transparency to stakeholders at the level (feature and release) required to make key decisions.

These elements are mutually reinforcing. It’s hard for a team to deliver well and consistently over the long term with significant shortcomings in any area above. Critically, because variability compounds exponentially with the scale and complexity of a system, it is perilous to believe your program is in control if its constituent teams exhibit significant shortcomings in any of these areas.

Please understand that I am NOT suggesting that if your teams aren’t perfect you mustn’t do release planning, or shouldn’t start implementing SAFe, or that you should delay implementing a “Release Train” to manage your big complex program. By all means, do those things in an informed and deliberate manner, while understanding the limitations of the plan, and aggressively improving the capabilities of the teams.

Indeed, planning should be done early and often, and planning at all five levels continuously is an important element of achieving flow and pull. Just remember that it’s essential to set expectations about the accuracy of plans generated, and to use the appropriate level of precision for the confidence you have in your stats, and for the time horizons in the plan, as errors compound over time.

Some corporate cultures make it very hard to share a plan without it being misconstrued as a cast in concrete “promise” in a destructive game that inevitably ends in finger pointing, recriminations, demoralized employees, and consequently retarded value delivery. Strive to set stakeholders’ expectations that a release plan generated at an early stage of agile maturity is:

1. based on a changeable (agile) backlog, thus is NOT a commitment
2. based on weak foundational stats, thus inherently inaccurate

If you want to scale agile, any significant shortcomings in critical team-level capabilities should immediately trigger an aggressive improvement program involving training, intensive coaching, technology investment, and organization and employee development. This is critical to scale to the program and portfolio levels with the transparency and consistent value delivery your organization demands, and it’s best to begin while leadership and team members have the energy and enthusiasm to effectively embrace the changes necessary to succeed with agile.

A Note on Metrics and Measures

Important Note: In any discussion of metrics and measures, I feel compelled to repeat some classic considerations to help avoid their (all too common) misuse:

    • Measure what’s important, not what’s easy to measure.
    • Poor metrics are worse than none (and incentives even more so).
    • No one metric tells a whole story- a balanced set is essential.
    • Understanding trends is more useful than trying to manage by snapshots.
    • Mismanagement will engender gaming. People are smart. Feeding gamed metrics to disengaged managers is easy if managers create reasons to do so.
    • Numbers don’t replace leadership and people, insight and active engagement, and can’t replace the need to collaborate and care.

There is more where that came from. Download our latest SAFe webinar”Hit the Ground Running:Design and Manage Your SAFe Implementation”

http://getagile.bigvisible.com/safe-framework-webinar/

Share:

A Very Agile Thanksgiving – Using Personal Kanban

A Very Agile Thanksgiving
Using Personal Kanban To Plan Your Holiday Dinner

The_First_Thanksgiving_cph.3g04961

Thanksgiving is almost upon us. For many, this is a joyous time of celebrating family and friends and giving thanks. For others (like those preparing for the actual celebration) the long list of To-Dos can seem a bit overwhelming.

One of the easiest ways to cope with this stress is to start practicing agile at home and using Personal Kanban is a great way to get started. Below is a step-by-step guide to taking the list of To-Dos and turning it into something that may give you another reason to give thanks this November.

Step 1 – Set up your Personal Kanban board

If you’ve got a big blank space on a wall near where you’ll be doing the work preparing for Thanksgiving, that would work great. If you don’t have that available, you could use BigVisible’s SeeNowDo or one of the many web based Kanban Tools like LeanKit. If you are working on a tablet computer, KanbanPad.

The easiest way to get started with this is to create a board with 3 columns: Ready, Doing and Done.  If you are really trying to keep with the practice of Kanban, you’ll also want to create a Work in Progress (WIP) limit, at least for the Doing column. The idea behind this is to minimize the amount of things you are working on at one time. If you set a WIP limit of 2 in the Doing column, then it means you can’t be working on more than 2 things at any given time. (Ideally you want a WIP limit of 1, but if you are new to this kind of thing and still believe in multitasking, this may help you keep from trying to do everything at once.

And if you have people helping you with the work, you may want to set the limit a little higher.

Step 2 – Build your Backlog

Grab a stack of Post-Its and make a list of all the things you know you have to do in order to prepare for Thanksgiving. Put one idea per Post-It and place all of them in the Ready Column. This will serve as your backlog of work. You may find it helpful to order (or prioritize) the list of items. If you are going to prioritize the list, you may want to order the items based on what is the most stressful, what takes the most time, or what is going to be the hardest thing to do. You should also factor in some idea of the order in which these things will logically happen. For example, it wouldn’t make sense to prioritize a work item to “Clean the Dishes” so that it reaches the top of the list before you get to “Cook the Turkey”.

Step 3 – Working the Backlog

Once you are ready to get started, pull the top item(s) into the Doing column and begin working on them. If you have a WIP limit, you should only pull in as many items as the WIP limit allows. So, if my WIP is 2, then I can have only 2 items in the Doing column at any one time. If you feel like you need to get started on a new item from the Ready column, you’ll need to complete one of the items in the Doing column first.

Each time you complete an item, move it to Done. It may not seem like much, but you’ll be surprised at the increasing level of satisfaction you get each time you get to move something into the final Done column.

If you’ve got people helping you, they can take and move items as well (keeping to the WIP limit). The idea behind all of this is to limit the amount of things we are working on at one time, get one thing completed and then start on the next item. If you are preparing the Thanksgiving-feast-that-will-be- talked-about-for-generations, you’ve got a lot to do in order to get ready. Staying focused on one item at a time will help reduce your stress, give you greater visibility into exactly what is left, and also help you coordinate the work with anyone on your team.

Step 4 – Lather, Rinse, Repeat

Keep working your backlog until everything is done, moving tasks across the board as you make progress each step of the way. As you move more items to the Done column, you’ll find that the overwhelming pile of things you need to complete is rapidly taken care of, allowing you to spend less time fretting about what has to be done, and more time celebrating with your family members.

Some Tips for Trying Personal Kanban

You may be tempted to skip the WIP limits and just pull everything into Done. This is a tough one – especially if you feel like everything has to be done anyway. Trust in this system, if only as an experiment. It’s been used successfully on projects far more complex than Thanksgiving and it really does work…if you let it.

If you have the ability to set up your “board” space near where you’ll be working (like your refrigerator), you will find it helpful to have it out in the open and easily accessible as you make progress. It will also let others know what you are doing, and hopefully they’ll join in to help.

One of the things I learned from my Personal Kanban experiment earlier this year was that it taught me how incredibly inefficient I have been with my work. If you find the same, just make a note of what you learn and keep it for after Thanksgiving. Once the dinner is over, the dishes are clean and you’ve recovered from the massive intake of turkey, cranberry sauce and pie, take time to hold a Retrospective. If you had helpers for the preparation, include them as well and talk about what you learned during your Personal Kanban Thanksgiving. Try to find some lessons you can take away and improve upon when you begin preparing for your next big holiday meal.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The SAFe Framework: Rigid & Prescriptive? Or Adaptable & Evolving?

SAFe: Rigid & Prescriptive? Or Adaptable & Evolving?

The Scaled Agile Framework (SAFe) is a hot topic in the Agile community these days. The Coaches and Consultants at BigVisible, like many elsewhere, have been debating the pros and cons of the SAFe framework for a year or two now. We’ve attempted to dispassionately compare and contrast results from our experiences rolling out SAFe at clients who requested it, to the results at Agile transformations done “The BV Way” in large enterprises over more than a decade. While specific differences between the approaches will be addressed in a later edition, let’s begin by examining common objections to SAFe, and considering their validity.


If you are new to the Scaled Agile Framework, start here. For information on the BV Way, contact BV or start here.

Constructive criticisms of SAFe usually address the apparent prescriptiveness and comprehensiveness of this intricate integrated framework.

These criticisms are based on the proven principles that:

1. Organizations are complex systems that evolve their optimal practices and structures as a result of observation, experimentation, and learning over time. One-size-fits-all solution frameworks can’t be as effective as self-tailored solutions evolved organically, nor do they teach the organization to learn and adapt, a critical capability.

2. Change “sticks” when buy-in and ownership of new practices and structures result from shared observation and learning; when new ways of working are developed by those doing the work.

3. People tend to underestimate the complexity, difficulty, and importance of change-management when you can just “buy” an “off the shelf” process framework. The appealing illusion that meaningful change can be prescribed in a nicely packaged graphic may actually diminish the likelihood of successful change, because organizations fail to embrace the commitment and investment necessary to implement change in large organizations.

4. The importance of leadership styles and the need to evolve legacy organizational cultures can be overlooked when one can just “implement a framework”. The foundations of Lean and Agile depend, above all, on the investment in, and empowerment of, people.The critics presenting these arguments correctly emphasize the tremendous value of having experienced coaches and consultants guide organizations through the journey of discovering and adopting new ways of working to implement successful and lasting change. Unique improvement objectives and business and cultural environments produce unique solutions.

These criticisms of SAFe emphasize some very important points, but they assume a dichotomy that doesn’t exist. They imply SAFe’s sponsors disagree,or would knowingly advise a client to underinvest in change management and self-discovery as a basis for continuous improvement.They present a straw-man argument that implies 1) the framework is intended to be implemented verbatim in its entirety, irrespective of context, and 2) that there is no need for a professionally managed change-management initiative to successfully implement SAFe in a complex enterprise. In my interactions with the SAFe community, and my experience becoming a SAFe Program Consultant, I have observed that the SAFe community values and supports:

• Encouraging organizations to inspect and adapt the way they work and support continuous improvement, to include customizing SAFe

• Engaging coaches and investing in the sponsorship and structures to support successful change management

• Embracing leadership and culture as crucial to any significant organizational improvement

Perhaps these points should be illustrated and emphasized more forcefully in the SAFe literature, but nobody I’ve met in the SAFe community is denying their importance.We have established that there are risks to providing too-pat answers to complex organizational challenges. Are there benefits from the SAFe framework’s comprehensive and prescriptive appearance? My experience is that there are.

For example:

BigVisible has observed that large enterprise clients often doubt their own organization’s ability to change. They reject case-studies because their challenges are “unique”, but often demand an illustration of their Agile end-state. Responsible coaches answer that a client’s future state will be emergent and non-deterministic, but the SAFe framework provides value because it helps clients see one concrete instantiation that probably supports many of their critical functions. SAFe’s clear and seemingly complete organizational archetype of Agile for large complex organizations reduces fear and trepidation. By illustrating a rich set of patterns proven effective in large enterprises,SAFe provides people confidence that they don’t have to invent every element themselves.

SAFe also provides an implementation template for getting a “release train” of teams rolling with a solid release-planning model. Giving clients confidence that SAFe is built on tested and proven structures that large complex enterprises have implemented successfully gives them confidence to move forward more aggressively. Many of us in the coaching community have long espoused release planning as crucial to program-level effectiveness. My initial reaction was that SAFe advocated release planning at an earlier stage of team maturity than I was comfortable with.In practice, though, I have observed the SAFe approach work as a forcing function to dramatically accelerate line-of-business planning,improve communication, and aid cross- team alignment. Like any pattern language, SAFe allows us to streamline communication and “get to the meat” of our process and structure debates by starting with a universally understood standard. Using known templates as a default or a position to offset from, helps us shortcut poor time investments, so we can focus our efforts on areas that reward innovation. I hope some of the points above have helped illustrate some of the risks of misusing a framework, as well as providing some practical insights to where and how SAFe has real benefits to large organizations attempting to scale Agile. Like any good craftsman, we have a wonderful variety of tools in our consulting toolbox.

I’m convinced that in the right setting, used by the right hands, SAFe is a tool that can provide great value to enterprises. In the next installment, we’ll emphasize the basics to have in place for successful scaling; the foundation of team practices and structures essential to support the scale and complexity addressed by the program and portfolio levels of the SAFe Framework.

Want more SAfe Framework Implementation Tips & Techniques?Join us for our upcoming webinar on December 13th, 10 a.m. PST/ 1 p.m. EST

“Hit the Ground Running: Design and Manage Your SAFe Implementation”

BigVisible Webinars CTA

Share:

Practical Systems Thinking: Don’t Let Inertia Become the Constraint

Congratulations! You’ve gotten to the fifth step in the Five Focusing Steps of the “Theory of Constraints”. That means you’ve broken the constraint in your system!

But, your work is not done. As a matter of fact, it’s just starting. You see, once you break a constraint in your system, a new constraint will always emerge. Yes, you elevated the throughput of your system, but, as you’ll see in this segment, you must be relentless about breaking the constraints that continue to emerge.

In Eliyahu Goldratt’s CD Series, “Beyond the Goal”, he discusses the dangers of inertia and what he means when he says ‘don’t let inertia become your constraint’. He’s referring to Internal Inertia, something we must combat against within our own team(s). In other words, don’t become content or complacent.

But, beware! There’s another form of inertia, one that is much more difficult to identify and overcome: External Inertia. It’s the “inertia” caused by the set “rules” within your organization, the “that’s the way we’ve always done it” mentality that may resist the changes you implemented when you broke your constraint. The challenge with these rules is that they were good, and even helpful, at one time, so people are reluctant to give them up. Teams realize that these directives were put in place to help the organization be more effective based upon the way it was operating. But now, they may not realize these precedents are no longer relevant since we’ve changed the game and the way we think about the system.

Check out this video as I expand on the concept. And if you missed any of the previous installments of “Practical Systems Thinking”, check out the “You May Also Enjoy” section below this clip.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Practical Systems Thinking: Elevate the Constraint

Practical Systems Thinking: Elevate the Constraint – The saga continues!

If subordinating to the constraint is the most challenging, elevating the constraint is the easiest…to get wrong. Elevating the constraint is the fourth step in the “Five Focusing Steps” of the Theory of Constraints, and all too often, teams do it first, before exploiting and subordinating. Sometimes we even attempt to elevate the system’s throughput by putting more resources on the project without even knowing where the constraint is in the system! (Does that sound like the Mythical Man Month to you?)

Elevating the Constraint is the first step that has us actually investing money in our system, so it would be wise to see if we can break the constraint by exploiting it and subordinating to it first. If you’ve broken the first constraint then move on to the new constraint. If the first constraint isn’t broken yet, then wisely invest by elevating it.

For this segment, I’m going to ask you to think a little deeper than just adding resources to the constraint in your project. I’ll ask you to look further into the constraint to understand what is really happening at the constraint to see what is constraining it. Check out this week’s video to see an example of what I mean.

Practical Systems Thinking: Elevate the Constraint

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Practical Systems Thinking: Subordinate to the Constraint

Subordinate to the constraint?? That doesn’t sound right! But that’s the third step in the “Five Focusing Steps” of the Theory of Constraints. It’s possibly the most challenging part of the process because it seems counter-intuitive and requires tremendous discipline when implementing it. Does that mean we’re “hitting the breaks” in this process? After all, “subordinating to the constraint” means that if you want to get more work through your system, you essentially have to do less.

In this fourth installment in the Practical Systems Thinking series, I’ll show you how introducing too much work into your system will cause inventory build-up in front of your constraint which, in turn, has a detrimental effect on your system. I’ll also show you how 100% utilization of resources in front of your constraint will cause you to lose your ability to exploit your constraint, ultimately reducing the throughput of your system.

Miss our previous installments? Check them out below, under the “You might also enjoy section”.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The Volume Knob

A Parable

Charlie walked into the stereo store. He was looking to upgrade his old home system to something that sounds better. He had a nice budget and expected to be enjoying rich, full sound by evening.

He found a system more expensive than he had ever spent but still in his budget. It had the usual controls with a large volume knob, loudness and so on. It also had equalizer sliders that would physically move seemingly by themselves when he fiddled with some preset mixes. Wow, that was cool! There were also some controls that had to do with echo, which Charlie knew nothing about.

Right then, Dave, a store employee, came over asking if he could help Charlie make a selection. “How do these different knobs control the attributes of the sound?” asked Charlie.

“Good question,” said Dave, with a smile. “I find that the sound output improves if I turn up the volume.”

Just turn up the volume?

Just turn up the volume?

“The volume improves the sound? What do you mean?”

“Well, I don’t really worry about all these other knobs. If the music is loud enough it sounds good enough to me.”

Charlie scratched his head. “Wouldn’t the music eventually get too loud to enjoy?”

“I don’t really understand how these other controls work,” said Dave chuckling. “It gets to be too much work to figure out what I should or should not adjust. So, I just turn up the volume until it sounds good.”

Puzzled, Charlie asked “Then why are all these other adjustments provided on the system? I could just buy that cheap system over there without all these controls.”

“Yep, you could do that,” agreed Dave, adding with a big smile, “But this system is so much louder!”

Is More Better?

Most organizations seem to have a “volume knob” that is the default action to get more output from anyone. And the “knob” is labeled “overtime,” “extra hours” or “startup mode.” Yes, these high quality people will make more output by working longer hours. Seems a waste of talent and creativity. Wouldn’t it be a better use of people to do what it takes to get the best outcome for the least amount of output?

Adjust The Treble

The most powerful way to a great product lies in deciding what to not create. The highlights and beautiful clearness of thrilling features can be muddied by trying to do too much. By adjusting the “treble” of your product, your teams can focus on giving the customer what they really want.

Drop The Bass

Teams running at full speed and overtime don’t have the time to create a technologically solid foundation. Unit tests, automated regression tests and continuous integration provide the “rhythm keeping bass” to your product. Ignoring the foundation of technical excellence leaves your product on shaky standing, no matter how many hours people work.

Watch The Levels

Every system of production has a constraint, that point where the capacity to work is restricted. Like the level display on a stereo, visualizing the flow of work through your teams can reveal the constraint. Changing your system to remove the constraint, even just “moving the equalizer slider” a little bit, has higher long term benefits than working harder.

Surround Sound

The value of being a true team can be unlocked by “surrounding” features and stories together instead of defining ways for individuals to work by themselves. Establish team work in process limits and other work agreements to create collaborative work.

Beyond The Volume Knob

There are many other possibilities to improve the outcome of your work. How about the “tuning” knob of validation, finding out if that feature really is what your users want. Or maybe the “balance” knob of pair programming. There are so many things teams, managers and organizations can improve that allows you to keep a sustainable pace.

Rich and Full, Not Loud

Bad sound does not improve with more volume. More output does not improve the quality nor the richness of your product. It’s just more. Find the “knob” in your organization that will enable “rich and full music” to your customers’ ears!

Pretend you didn’t have a “volume knob,” that people can work extra hours. What other product building adjustments can you make to create an even better “sound?”

Share: