Skip to content


How to Use an A3 in an Agile Transformation

Leading Agile - Mike Cottmeyer - Mon, 08/31/2015 - 16:02
What is an A3

An A3 is more than an 11 x 17 inch piece of paper that is structured into several sections and not all A3’s are created equal. An A3 is a structured problem solving and continuous improvement approach, first employed at Toyota and typically used by Lean manufacturing practitioners. What your A3 looks like depends upon the situation. The example below consists of the following pattern, as part of an Agile Transformation:

  1. Current Situation & Problem
  2. Root Cause Analysis / Conclusion
  3. Goal
  4. Corrective Action

After we agree on the four steps, we’re going to implement the correction action and then verify the results. The content of an A3 follows the logic of the Plan-Do-Study-Act (PDSA) cycle.  What I want you to take away from this blog post is not so much TQM, PDSA, and A3’s, as much as how you could benefit from them when doing an Agile transformation or any kind of process improvement.

a3 example for transformation

When doing an Agile Transformation, I’m going to always cycle back to 3 core goals.

  1. Form complete cross functional teams
  2. Build backlogs
  3. Deliver working tested software

Anything that gets in the way of doing these is an impediment that has to be removed.  The example I have above describes how a team is under-committing each sprint.  We’re using a story point completion ratio to know if the team is delivering working tested software. We’re going to use this single page to have a shared understanding with our client and agree on a course of action.  Now, I’m not saying you have to use this template. If you can remove an impediment informally, by all means, do it!  But, to make sure my client agrees there is a problem that needs to be prioritized and addressed, this is an effective tool and it’s pretty lightweight.  You may also notice I don’t call this an A3 on the actual example.  I’m going to call it an Action Report so my client feels comfortable with common language and I don’t need to distract them by introducing Lean terminology.  When I say “A3″, there are certain expectations.  Let’s not get hung up on that and just call it an Action Report going forward.

Flow of the Action Report

You’ll notice that I structured my Action Report so that your eyes will be drawn to sections. I want to compare 1 and 3 (Current Conditions and Goals) and 2 and 4 (Root Cause Analysis/Conclusion and Corrective Action).  This allows a transformation consultant to note impediments and identify root causes independently but then be prepared to collaborate with the client on goals and corrective actions.  I’m going to stress this again.  We’re only going to go through this process if the consultant can’t resolve the issue informally.  If not, he or she will need to collaborate with the client to confirm the goal and agree on an appropriate action. The consultant doesn’t do all of this in a vacuum.  When looking at action (or A3) reports used by others, I’ve seen them identify the goal prior to looking for root cause. From my experience, if I’m required to identify the goal before moving forward, this may create an unnecessary delay.  If I don’t think something is right, I’m going to start investigating right away and then circle back with the client to validate their goal. But, I’m not going to stop and wait to be told what their goal is before beginning to look for root cause. I don’t want to stop until my personal curiosity is satisfied. Also, I’m not saying to not collaborate with the customer. I’m saying keep moving forward on multiple fronts and to circle back at the first logical opportunity.

Current Conditions

We have several opportunities during the transformation to get this information.  It could be, we just completed a formal assessment of the team or organization.  Maybe we just reviewed metrics of the team or organization.  Maybe I just walked out of a really long and unproductive meeting. Whatever we did, I’m looking for some kind of objective criteria or indicator to describe the condition.

Root Cause Analysis / Conclusion

In order to propose appropriate corrective actions, we need to identify the root cause of the condition. Avoid using logical fallacies like anecdotal, appeal to emotion, or false cause. I like to use Socratic method or ask the 5 whys to help reach the root cause.


The goal listed above in the illustration focuses on getting a team’s story point completion ratio to 100% +/- 10%. This goal is pointing back to building backlogs and delivering working tested software.  By getting the teams to keep their commitments of delivering working tested software regularly, we allow the business to make better commitments to their customers. If we can build that trust and safety within our organizations, we’ll start to build balanced systems.

Corrective Actions

Identify corrective actions that is both short term and easy to implement. If the actions are neither, I keep a higher level corrective action around and then break it down so I can incrementally work toward the goal.  Personally, I keep my daily activities on a Kanban board. For an overall transformation, I keep the actions and activities in a rolling 90-day plan.  This keeps the client informed on what value I’ve delivered and what value I plan to deliver in the coming weeks/months.

Plan Do Study Act in an Agile Transformation

When doing an Agile Transformation, PDSA is just one pattern to map the approach.  Not mentioned in this blog post are the original inputs into the initial coaching plan and 90-day plan. (both of which are collaboratively defined and continuously evolved with the client). But, how do I fit it all together in a high level “plan do study act” process, more emblematic of the original A3 process? I use the following:

  1. Coaching Plan (Plan)
  2. Rolling 90-Day Plan (Do)
  3. Adoption Assessment (Study)
  4. Metrics (Study)
  5. Action Report (Act)

Plan Do Study Act


I hope this provides some insights into how you can take some of the hand waving out of your next (or current) Agile transformation.  There are a lot of moving parts and you need the process and tools to keep an eye on your goals and manage progress, without adding so much overhead that you stifle the forward momentum.  Let me know if you have questions!

Download a free copy of the A3 – Action Report Template


The post How to Use an A3 in an Agile Transformation appeared first on LeadingAgile.

Categories: Blogs

Building ES6 Browser Apps w/ Babel and Grunt

Derick Bailey - new ThoughtStream - Mon, 08/31/2015 - 13:30

Over the last few months, I’ve spent a lot of time learning some of the new features in JavaScript ES6 (ES2015). I’ve recorded most of this as a live series of screencasts on WatchMeCode, and have made these episodes available already. Along the way, I also started using ES6 features in my day-to-day JavaScript development for client work. What I found in doing this, however, is that I needed a few more tools in place than what I was showing in my WatchMeCode episodes that covered specific features.

Having built a fairly solid workflow for my projects, I decided to share my setup by recording a live episode where I walk through the process of creating an ES6 based browser application.

Building ES6 Browser Apps

In this special, live episode of WatchMeCode, you’ll see the tools and processes that I use to build ES6 features in to my applications today. You’ll also get a quick look at a few of the ES6 features themselves, but the primary focus will be on the build tools and workflow.

Learn More About ES6

If you’d like to learn more about ES6 – the features shown in this video and many other features that I’ve come to rely on in my day to day work – check out WatchMeCode’s live series on ES6 (requires monthly subscription), and these episodes in particular:

At only $14/mo, there’s a lot to learn already and there’s a few more episodes to come covering ES6 classes!

Categories: Blogs

Writing for SearchSoftwareQuality on Agile, Quality and Continuous Improvement

Ben Linders - Mon, 08/31/2015 - 12:54
I started working freelance with SearchSoftwareQuality to share my experiences with Agile, Quality and Continuous Improvement. SearchSoftwareQuality is an online community provided by TechTarget, a leading online technology media company. Continue reading →
Categories: Blogs

Why I Am Not A Change Agent

Agile Thinks and Things - Oana Juncu - Sat, 08/29/2015 - 18:56
The New-New Mr. Smith, The Change AgentHow do you present the job that you do ? Write it down.
Now see if words/expressions  like "help", "become", "improve", "how to", "implement"  "change", "need to", are part of your description.
If some of these are present in your description, take a moment and make two groups. Put those words that you used as applying to others,  in the 1st group. Then put those that refer to yourself in a 2nd group . How many items are in the 2nd group in respect with those in the 1st one ? What these numbers tell you ? Well, I'll tell what they have told me. Help ( euh, and coaching ... ) Cannot Be Pushed On People If you're called  to provide a given expertise when working with people and organisations, it might be tempting to "force in" your expertise. If you're successful , those people you're working with,  will acquire the necessary knowledge to operate in the field of your expertise. Faster this will be true, more efficient you'll be. Simple as that, this is the end of the story, unless it's not.  If would have been a dead end . Mandated expertise and "help" are some of those privileged impossible things that find themselves a cosy corner in the sweet spot of wishful thinking.
If I say ( e.g.) "I help organisation improve their team work" , it actually reflects my wish to be such a great professional who can help improve team work.
Help is the qualification of my work from my perspective. The same service I provide might be experienced by those that receive it (the helped people, you know ...) as little value overwork, meaningless noise ...
Real help  can be qualified as such by people that received it.
That's why I know I'm no professional helper for  any individual or organisation. I host containers that people fill in with their context and the change they want to see.
Well, if I'm not helping,  let's see what may chances are to be a change enabler ...

Culture : From Values To Biases And BackNo change will happen until the culture will let it. OK, so focus on culture ! I do believe culture gives a group an identity . I do believe individuals influence culture .  I do believe culture gives a sense of belonging .
Either you join a culture because its principles are aligned with your values, either you live by it( like the one you are born in) and learn to prise and nurture its values.
The set of values is the foundation of each culture .  The set of common beliefs is the set of practices that result from prizing those values.Let's say we live in a culture that values "cleanliness" most.  What will be our understanding of a culture that values "spare water" most?  What will be their understanding of ours?  What if instead of genuine observation we start to "rate" the set of values on a scale that has as reference our own values ?  This is at least irrelevant at worst dangerous .

History have had some many, many tragic examples.
No change will happen until the culture addressed by that change will let it.  If changing culture needs a shift in group's values, better start to shift my own ones.  It's the "start with yourself" principle of congruence . This having being said, the task is in no way easier.  If I start with myself, hmmm, let's say I've got this, what will I start with ?
Remember the "cleanliness" and "spare water" cultures mentioned roughly 10 lines above ?
"Liminal Thinking", a pattern defined by Dave Gray offers an alternative to "value the values of other cultures by our own values" . Great Stuff !
First we're invited to start the journey to ourselves by accepting a statement :
"The reality where I'm comfortable in, with my people, my cats, my umbrellas , my Agile principles ;) - is just set of beliefs I've built far from the real reality that, by the way, I don't even have a clue want it is".
From here, we can continue the journey into assumptions that created those believes ,  needs that generated those assumptions, experiences that we recall as relevant to our needs.
Why is this helpful ? Because we might realise why , and realise that other cultures have their own "whys".

I Have No Idea If I Help 
If I'm in my group and my beliefs are my reality and of those I respect and care , why should I care if my reality is different of people that I might not care of and respect so much ?  Because at some point,  either their reality floods our cosy bubble , either I might have that fancy job description ( remember , it is now about  40 lines way up in this post ! ) that says I "help"  other people change , and they might not be so wildly willingly to recognise me as the best next Messiah they can get.
If I stay in my own "Self-Sealing Bubble" I might get angry or frustrated because "they just don't get it".
If I inspect my bubble I can share the story of why I'm in and shake it to take a limp in the liminal space outside of it . Then ask questions and invite to answer,  like Alice in Wonderland does. Alice is never angry , nor frustrated and has no idea if she shakes Wonderland.
Is this ... "help" ? Even farther, is this ... "help to change" ? I have no idea . That's why I'm not a change agent. When I first made the exercice I made up and proposed in the beginning of this post,  now a far 60 lines up to the top,  I fixed myself a goal : get rid of any of those words in the group that applies them to others . And get rid of them in the group that applies to myself , because they might be irrelevant to anyone but me.
 To steal an expression I heard in a open Space chat at ALE2015 with my  Trust Artist friend Olaf Lewitz I'm just "shaking" myself . See if anything happens.

Some Material To Promote Myself ( because it make me feel cool)
I held an workshop at the Agile2015  on Dave Grey's model combined with the archetype of "Third culture kids"  to trigger awareness of our Agile self-sealing bubble :) .
The support is here

Related posts and other cool stuff Into The DNA Of A Culture
Agility Adoption Rather Than Agile At Scale
The answer to "Why" Is Ahead A Geography of Time , R. LevineThird Culture Kids, David C. Pollock
Categories: Blogs

The Ultimate Personal Productivity Platform is You

J.D. Meier's Blog - Fri, 08/28/2015 - 22:25

“Amateurs sit and wait for inspiration, the rest of us just get up and go to work.” ― Stephen King

The ultimate personal productivity platform is you.

Let’s just put that on the table right up front so you know where personal productivity ultimately comes from.  It’s you.

I can’t possibly give you anything that will help you perform better than an organized mind firing on all cylinders combined with self-awareness.

You are the one that ultimately has to envision your future.  You are the one that ultimately has to focus your attention.  You are the one that ultimately needs to choose your goals.  You are the one that ultimately has to find your motivation.  You are the one that ultimately needs to manage your energy.  You are the one that ultimately needs to manage your time.  You are the one that ultimately needs to take action.  You are the one that needs to balance work and life.

That’s a lot for you to do.

So the question isn’t are you capable?  Of course you are.

The real question is, how do you make the most of you?

Agile Results is a personal productivity platform to help you make the most of what you’ve got.

Agile Results is a simple system for getting better results.  It combines proven practices for productivity, time management, and motivation into a simple system you can use to achieve better, faster, easier results for work and life.

Agile Results works by integrating and synthesizing positive psychology, sport psychology, project management skills, and peak performance insights into little behavior changes you can do each day.  It’s also based on more than 10 years of extensive trial and error to help people achieve high performance.

If you don’t know how to get started, start simple:

Ask yourself the following question:  “What are three things I want to achieve today?”

And write those down.   That’s it.

You’re doing Agile Results.

Categories: Blogs

An Aggressive But Realistic Delivery Date?

Leading Agile - Mike Cottmeyer - Fri, 08/28/2015 - 15:06

I recently received an email asking about release planning. The sender wanted help understanding how to move ideas through the flow to create a mature backlog. The note went on to ask how to properly “estimate, prioritize and reach an aggressive but realistic delivery date”.

My immediate thought was, this is agile: total project story points divided by team velocity yields the duration of the project. And delivery date then only depends on when you start and how well you manage risks and dependencies. If you want an “aggressive” or what I’ve come to understand as “overcommitted” plan you should just crack out your Gantt charts and stop pretending that you’re agile.

Before I dashed off a sharp email, I chatted with an associate and came to a different understanding of “aggressive planning”. He made the point that teams may not be aware of unused capacity. And establishing an accurate team velocity is a “trust but verify” process. Trust the current velocity, but periodically verify its accuracy. After a team establishes a sustainable and consistent delivery velocity, you should run an experiment. Increase the number of story points planned for a sprint by some number. If the team successfully delivers the sprint, then that total number of points is used for planning successive sprints. If the team sustains that pace, then reset the team’s velocity to the new number.  Run the experiment again.

This cycle of experiments continues until the team can’t keep up. At that point you have verified the team’s velocity as the last consistently maintained pace.  This final velocity is likely a bigger number (more aggressive) than the starting velocity number and so now a project’s duration will be shorter than calculated with the untested velocity. But the new velocity is verified; consider the date realistic.

The post An Aggressive But Realistic Delivery Date? appeared first on LeadingAgile.

Categories: Blogs

Publications on the Business Benefits of Agile

Ben Linders - Thu, 08/27/2015 - 23:13
I have collected research, studies and reports that provide insight into the business benefits of agile in a new agile and lean tool: Business Benefits of Agile. Continue reading →
Categories: Blogs

A Scrum Master Job Description

Illustrated Agile - Len Lagestee - Thu, 08/27/2015 - 16:22

I have been asked over the past couple of months by a variety of folks to share a template to use when creating a job posting for hiring a Team Agile Coach (or Scrum Master). I’ve had a few versions over the years but here is the latest compilation of my thoughts. Share any suggestions or improvements in the comments below.

Position: Team Agile Coach (Scrum Master)

The Scrum Master is a vital role in our company. You will be in the unique position to help us coach, guide and facilitate a vibrant, energetic, and inclusive culture while delivering amazing things for our customers.

Here is how you can have a part in making this happen:

Facilitate team and organizational flow.

  • You are coaching the team (and organization) to deliver value incrementally by creating experiments and by building small things – flowing from hypothesis to something real. We are doing big, important things but we are learning as we build in short iterations.
  • You are focusing on the “why” and “how” instead of the “when.” While the “when” is important, of more importance is the understanding of why the organization is functioning the way it is. You can then help to remove any impediments keeping us from delivering as quickly as possible. The “when” will take care of itself.
  • You are the conscience of the team. Similar to a heart-rate monitor while exercising, you are gauging if the team is over-committed, under-committed, or delivering optimally and can guide them back into flow if needed.
  • You are helping your teams to transparently and continuously radiate information about their progress and the results of their experiments.
This means you are facilitating an environment for your team to organize themselves around their work, help them become self-aware to what is blocking results, and to influence them to become self-healing or self-correcting.


Guide an inclusive environment.

  • You recognize the importance of every human on your team and take personal responsibility to ensure each voice is heard and each person valued.
  • You appreciate the diversity assembled on your team and can help each person to contribute during the journey of delighting our customers.
This means you have strong listening and observation skills and can engage with your team when necessary to promote inclusion and build connections.


Intentionally design resiliency.

  • You know how fast the world is changing and the way we work together today may be different tomorrow.
  • You understand that your team, because of how quickly things are changing, may be touching the fringe of chaos at times and you are comfortable with this.
  • You are a student of many frameworks, methodologies, approaches, concepts,and perhaps, cutting-edge organizational design ideas. This allows you to choose from a variety of techniques to help strengthen your team through the chaos.
This means you are designing events and activities to allow the team to experience and thrive in change instead of forcing rigid, unnecessary process and overhead on them.


Foster an amazing workplace environment.

  • You are an encourager and a positive force throughout the organization.
  • You are coaching people to get to know a little more about each other and to learn about what what motivates them. You are a connector of people.
  • You are frequently sharing experiences with your peer Scrum Masters and coaches to support and learn from each other.
This means your presence helps bring out the best in others and creates an atmosphere where people are excited to come to work.


What we would rather not have you do:

  • Be the “process police.” You are a facilitator, a teacher, an observer, an encourager and a coach…not an enforcer. We need you to guide and serve your team.
  • Be dogmatic about any methodology or framework. We need you to actively assess the environment and use your best judgement to pull in the right technique or approach for each situation.
  • Be the “task master.” We would like you to coach pull and flow. You will need to recognize when you should step away a bit and when you should let go of control from time-to-time.

Feel free to use any piece of this in your next Scrum Master job posting. Hope it helps! Again, add any suggestions by replying below.

Becoming a Catalyst - Scrum Master Edition

The post A Scrum Master Job Description appeared first on Illustrated Agile.

Categories: Blogs

Designing a build pipeline is about impatience

When I'm designing a build pipeline I'm primarily thinking about my impatience.

How long am I willing to wait to get feedback?  Given how long I'm willing to wait, how confident am I about the quality of the feedback?

I'm not so concerned with whether it's a "unit test", an "integration test", or whatever.  My criteria is not based on what type of automated check is in the build stage so much as how long the automated check takes.

For example...

Categories: Blogs

80/20 Product Ownership Updates

Agile For All - Bob Hartman - Wed, 08/26/2015 - 18:31

A few updates on 80/20 Product Ownership, my online course that teaches you how to slice your work at every level of detail to get value and learning faster…

New Bonus Units

Not only do participants get lifetime access to the content, but I also try to make the course more valuable over time based on feedback I get from participants and clients. To that end, I’ve added two new bonus units to the course:

  • “Killing Sprint Zero,” which looks at the practice of Sprint 0, how it delays value and learning, and how you can minimize or eliminate it.
  • “Reporting Release Progress,” on how to report progress on larger releases to stakeholders in a useful and honest way.
Feature Mining Webinar

Of all the content in 80/20 Product Ownership, I’m most excited about Feature Mining, my technique for taking a big idea (a new product, project, release, or whatever) and finding the first high-value, high-learning slices. 80/20 PO is the only place I teach this outside of in-person training and coaching.

On September 18, I’ll be hosting a live webinar on Feature Mining for all course participants who have completed that module. I’ll share more detail and examples of the technique, answer your questions, and provide feedback on your Feature Mining examples, master class style. To join the webinar, you’ll need to have completed the Feature Mining module, including practice activities and quizzes, by September 17. For eligible participants who can’t make the live webinar, I’ll make a recording available so you can still benefit from the session.

Sign up for 80/20 Product Ownership today to join the webinar.

Remote Coaching Offer

Finally, I’m offering a special package for five 80/20 Product Ownership participants.

There’s nothing like interactive coaching to learn these techniques and apply them to your work. Right now, there are two ways to learn this content—through in-person coaching with me or through 80/20 PO on your own. To bridge that gap, I’m offering a new package called 80/20 PO Mastery that includes registration in the online course plus two 45-minute coaching calls with me to help you apply the material.

We’ll work together to schedule the calls for the most strategic times in the course based on your needs. I’ll help you get unstuck, see new ways to apply the techniques to your unique context, and stay focused as you work through the course.

If you want to go through the program with a colleague, one of you can sign up for the regular course, the other can sign up for 80/20 PO Mastery, and you can do the coaching calls together.

Sign up for 80/20 PO Mastery here before it sells out.

The post 80/20 Product Ownership Updates appeared first on Agile For All.

Categories: Blogs

The Product Roadmap is Not the Project Portfolio

Johanna Rothman - Wed, 08/26/2015 - 15:38

I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management.


Several potential teams affect each project (or program).

Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization.

The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on.

The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work.

When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time.

When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time.

When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often.

All of these teams have dependencies on each other.

The project portfolio team optimizes the organization’s output.

The product owner value team optimizes the product’s output.

The product development team determines how to optimize for features moving across the board. When the features are complete, the product owner team can replan for this product and the project portfolio team can replan for the organization. Everyone wins.

That’s why the product owner team is not the project portfolio team. (In small organizations, it’s possible people have multiple roles. If so, which hat are they wearing to make this decision?

The product roadmap is not the project portfolio. Yes, you may well use the same ranking approaches. The product roadmap optimizes for this product. The project portfolio team optimizes for the overall organization. They fulfill different needs. Please do not confuse the two decisions.

Categories: Blogs

Roadmapping with Enterprise Agile – Balancing Capacity Against Demand

Leading Agile - Mike Cottmeyer - Wed, 08/26/2015 - 14:46

Frequently I’m asked:

There is a seemingly endless set of good ideas that are demanding capacity in our organization, how do we make our demand and capacity visible so that we can create a roadmap that will best balance demand against capacity?

This is the key question that most organizations are struggling to answer while trying to create an actionable roadmap.  I have a couple of basic rules that I use to help keep the answer simple.

  1. Identify a common unit of measure for quantifying demand and capacity, and
  2.  Identify a unit of time that best represents the period of time that will be used for planning

Rule 1: Identify a common unit of measure for quantifying demand and capacity

As you may recall, my favorite unit of measure is always currency.  That said, I find that when roadmapping it’s frequently helpful to use a more abstract measure that will similarly represent both capacity and demand.  Currency provides too many variations as an answer to the question “How much of this do you want to invest or how much capacity will you spend to bring idea x to fruition?”  To address this, I typically recommend that an organization either use a program team or a delivery team as the unit of measure.

With the common unit of measure set to either program or delivery teams, we can now answer the following question to help with balancing demand and capacity:

We have 20 delivery teams worth of capacity available, how many of them are we either willing to dedicate towards bringing this idea to market or how many do you think you will need to bring the idea to market?

Rule 2: Identify a unit of time that best represents the period of time that will be used for planning

This is a great start; but, we haven’t yet applied time to the process.  To really map demand against capacity we will also need to be able to answer the question of how long are we willing to apply the team to this idea.  If a planning team needs to release items into the market within months then I tend to encourage them to plan against team weeks.  If their release plans are more oriented around quarters, half-year or year durations I will usually steer them to think in terms of team quarters.  With both the unit of measure and unit of time selected we can now map both capacity and demand for a period of time.  As an example, I may answer the above question as follows:

I am willing to allocate 5 delivery teams for a quarter to bringing this idea into the market.  That will leave 15 teams worth of capacity open for other ideas or features that I want to create as well this quarter.

Using team weeks or quarters as a unit of measure and planning duration for your roadmap enables a planning team to simplify the capacity that is available by planning period down to a ratio of planned capacity/available capacity. (Eg.  5/20 or 25% of the available capacity for the quarter, with the above example).

Finally, when the time is right, it is possible to translate the cost of a roadmap item by establishing an average cost per team (say $250,000 per quarter) and then multiplying that cost by the number of teams allocated for the period.

What are your thoughts? Have you used anything similar or different?


The post Roadmapping with Enterprise Agile – Balancing Capacity Against Demand appeared first on LeadingAgile.

Categories: Blogs

Building A Component-Based Web UI With Modern JavaScript Frameworks

Derick Bailey - new ThoughtStream - Wed, 08/26/2015 - 13:30

Most modern front-end JavaScript frameworks provide some sort of support for component based development. This is an incredibly important step in the direction of development for the web. Components provide a way to write small parts with a consistent API that can easily be orchestrated as part of a larger screen, application or system.


Component based development isn’t just the future of the web, though. It’s what you should be doing now, in any modern UI / application framework on the web.

What Is A Component?

There are a lot of definitions of “component”, including those from electronics, system design, software and more. From a generalized software perspective, Wikipedia says

An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data).

This is a good place to start, for a high level, but we need to go further than this when talking about components within an application and a UI. Again, from Wikipedia:

[…] components communicate with each other via interfaces. When a component offers services to the rest of the system, it adopts a provided interface that specifies the services that other components can utilize, and how they can do so. This interface can be seen as a signature of the component – the client does not need to know about the inner workings of the component (implementation) in order to make use of it. This principle results in components referred to as encapsulated.

Now we’re on the right path: an encapsulated set of behaviors or process and logic, with a well-known interface or API to access that component’s functionality.

An Example UI Component

Expanding on this definition, it is easy to include a user interface in the definition of components. Rather than looking at individual controls, such as input boxes, drop down lists, labels or paragraphs, a component a set of behaviors that encapsulate related controls and the behavior associated with them.

For example, a component in a web application’s UI could be the display panel used to show an employee’s information, such as their name, email address, employee id and more. This component may include buttons to edit the employee or other controls to perform other functions as well.


What makes that example a component, in the end, is not just the code that controls it and the UI that represents it on the screen. Rather, it is the encapsulation of this behavior, UI and associated code and configuration, in to something that is easily orchestrated in to a larger system.

A component is a small, potentially re-usable set of logic, behaviors and interface elements (UI or API). And without components or component-based UI development, our applications become monolithic spaghetti monsters and nightmares.

The Benefits Of Components: A Short Story

It’s easy to think of components in terms of re-use. This is an unfortunately limited perspective, however. Developers tend to look at the word “re-use” and think that they need not bother with that since the code in question will only be used once. This perspective can be fallacyand can severely limit the actual usefulness of code.

The Project

Imagine, for a moment, a project that you’re working on. It may be for a client, or for your company internally. In this project, you have several screens in a workflow that mirror an older paper system. As you are putting together a new screen to model the next step in the process you realize that there is a problem. Part of original paper workflow did not make sense in the new software model. Due to the intelligent nature of the software, some of the information that was previously on a later page in the paper process should be moved to an earlier stage in the software.

The Estimate

After thinking through the changes and ensuring the logic of what the software needs would work correctly, you head off to talk to the project lead. The lead agrees with your changes and your reasoning – the software version of this process will be greatly improved with this change.

Being asked for an estimate to make the changes brings a sigh, knowing that it will probably take longer than you want to admit. But, with a brief conversation about deadlines and timelines, the project lead agrees to let you make the changes and gives you the three days that you asked for.

The Changes

Back at your desk, you settle in to make the changes. It’s a new system and it has been built with a component-based architecture that you’re not quite used to working with. The interfaces for each of the components you need to move around are consistent and fairly simple, however.

Each part of the screen has been well encapsulated in to a set of files and a common API. And in spite of these pieces only being used once within the application, you like the component-based approach.

20 minutes and a lot of cut & paste later, you have moved things around in the file system and then in the code to change which components are used where. With a sudden realization of what you’ve done, you look up at the clock. The changes that you had estimated at 3 days of work – based on your knowledge of how software was built previously – are done!

The Truth

It sounds like a fantastical story – a fairy tale of software engineering dreams. Yet this is exactly what I experienced while working on a system that I was building for a client in late 2012. I offered a 3 day estimate for a change that I saw as necessary. The client agreed in spite of the timelines we had to work with. To my surprise, I completed the changes in less than 20 minutes.

It may sound like a fairy tale, but it is the truth.

Component-based application development can significantly increase your ability to change the software to meet new requirements.

Components In Modern Framework

The project I built way back when, was done with with Backbone and Marionette for a client. At the time, it was cutting edge Backbone. I have since repeated this success many times, across many clients and projects. I’ve also watched the rest of the Backbone community and other frameworks move in this direction, since that time.

So, what do components look like in the most popular frameworks, these days? Not surprisingly, they all have a few things in common even if there are some differences in core syntax.

Ember Components

Ember has the idea of components baked in to the framework, and I love the way they describe componentsin the documentation:

HTML was designed in a time when the browser was a simple document viewer. Developers building great web apps need something more.

[…] Currently, you are limited to the tags that are created for you by the W3C. Wouldn’t it be great if you could define your own, application-specific HTML tags, then implement their behavior using JavaScript?

That’s exactly what components let you do.To build an ember component, you need at least two parts:

  • a declaration of the component as code
  • a template for the component’s UI

There are several examples of components on the Ember website, including a slick demo of a gravatar image from their homepage. (Note: this code works in Ember.js v2.0 – not guaranteed to work anywhere else, but it probably will.)

The first file declares the component’s code and behavior, while the second file declares the view template for the component. Once you have these in your components folders, you can use them in your app.

Notice how Ember allows you to add the component to the <li> by specifying a {{gravatar-image}} element? This is an important part of UI based component declaration and use – being able to reduce the amount of code where the component is used.

Angular Components

If you’ve done any work with angular, you’re already working with components. The entire directive system in angular is a look at how to build entire web applications out of components.

While Angular calls these “directives”, they are components in themselves. Looking at the documentation for creating a custom directive, shows this description:

At a high level, directives are markers on a DOM element (such as an attribute, element name, comment or CSS class) that tell AngularJS’s HTML compiler ($compile) to attach a specified behavior to that DOM element or even transform the DOM element and its children.

When I read this, I can’t help but see “application specific HTML tags” and “behavior using JavaScript” from the Ember documentation… Angular may use slightly different language, but the meaning is basically the same.

Functionally, the declaration and use of an Angular directive is also similar to Ember’s components, in that you need two things:

  • a declaration of the directive in code
  • a declaration of the directive’s template

From the Angular documentation, a simple directive can be created to display a name and address.

Again, the first file declares the component’s code and behavior while the second file provides the UI template. To use this, a “my-customer” attribute is added to a standard HTML element.

Angular takes a slightly different approach in the syntax, but the general end result is the same as the Ember idea of a component. You have some markup that gets interpreted / compiled in to additional HTML output with associated behavior.

This UI-first approach to components isn’t the only way to get components in to your app, though. There’s also a code-first approach that I’ve used a lot with Backbone.

Backbone / Marionette Components

When building components in Backbone, you’re going to need a couple of things, once again:

  • A declaration of the behavior in code
  • A view object to manage the UI
  • A template to use for the UI

Things are going to look different with Backbone than with other frameworks because Backbone doesn’t have a built-in mechanism to expand a custom element or attribute in to additional HTML or JavaScript behaviors.

Instead of declaring an element and getting behavior with it, you have to create an instance of the behavior and tell it where to use that behavior in the UI. To get that, you need a way to manage the workflow in your application. I typically bring in Marionette.js for this, but it can be done without that extra library.

The first two parts of this a component in Backbone / Marionette are going to look similar to what has been shown in other components:

The major difference will be found in the presence of a 3rd part: the component controller. In my applications, the controller is typically a workflow / mediator that receives a Marionette.Region. This region object is for displaying the component in the right location in the UI. Separating the code from the placement of the component decouples the component from the location in which it is used on the screen.

In this case, a Marionette object is acting as the workflow / mediator. It creates a Marionette.Region and forwards that to the component. To use this component, an instance of the controller is created, passing in the region, and the “show” method is called.

The disadvantage that Backbone has in the realm of components is adding that third layer as a component controller. This does introduce more code in comparison to Ember and Angular. The advantage that this creates (other than being able to use Backbone) is ease of composition inside the component. Since the component already has a controller with a separate view object, it becomes easy to add more views and behavior to be coordinated within the component.

I’m sure this type of composition is possible with Ember and Angular, of course. You’ll probably end up with a similar 3rd layer in these other frameworks, to coordinate multiple components and parts – so it may be a bit of a wash in terms of benefit / detriment, here.

Backbone isn’t the only oddity around, when it comes to components, however. With the recent rise of React, the JavaScript community is seeing something old turned new again, and with very interesting results.

React Components

React is an intriguing framework in many ways that I won’t cover here. From a component perspective, though, some of that intrigue comes from the combination of what has typically been two separate things in previous component syntax.

Rather than separating the UI template and code with behavior, React tends to combine the two. For example, Eric Elliot has an introductory article that shows a very basic React component being built.

In this example, a very simple “hello world” component is created with React and both the HTML markup and the behavior of the component are encapsulated into a single file! Yes, your component still need both UI templating and behavior, but React allows you to do these things in a single file / chunk of code, unlike virtually every other component that has been demonstrated.

To use this component, you render it out to the screen. As an example (again, taken from Eric’s article):

The call to render this component includes the <Hello/> tag, with parameters specified as attributes in the tag.

While Backbone / Marionette took the code-first approach to an extreme and required you to write more code than other frameworks, React seems to take the HTML element approach to a minimal extreme. You write all of your code and markup in one place, and use a custom element to render the component.

The Future Of Components

From these major JavaScript application frameworks, the majority of them take a custom HTML element approach. They allow you to define elements and use those elements within your application’s markup. Placing the custom elements provides the entry point for the component in the UI as well as in the behavior.

While I come from a background of code-first components (with WinForms applications, as well as JavaScript applications), I can’t deny the value and appeal of custom elements. It also looks like this will be the winning mode of component based development for the web in the near future.

Web Components / Polymer

Web Components are supposed to be the “all-in-one” future of the web… maybe. They are a standard by which developers will be able to build browser and framework agnostic components, to be re-used across the web as needed – regardless of what the rest of the website is built with.

I say “maybe” because complete support for them is very limited – basically, Chrome and Opera are the only browsers that support them. Firefox is even on record saying they aren’t going to go forward with them at this point.


If you want to use Web Components now, you have to use 3rd party libraries like Polymer. While this is a great suite of tools and technologies, it isn’t “native” web components, which means it brings along some limitations.

The idea behind Web Components is solid, even if the technology is only baked in to a few browsers at this point. As the Ember website says in it’s component documentation,

HTML was designed in a time when the browser was a simple document viewer. Developers building great web apps need something more.

The various standards bodies around HTML and JavaScript have recognized this, and Web Components are an attempt at finally fixing it in a common and standardized way.

But, as TJ Vantoll says, web components are not ready for prime-time yet. It’s probably best to wait for some of the remaining issues and compatibility problems to be resolved.

Build Components In Your Framework Of Choice

Components are critical in building larger applications. Without them, applications tend to become a mashed up mess of spaghetti code with tendrils and tangles reaching out across the depths of the system. The future of applications and UI on the web is component-based. I have no doubt about that, because the current round of JavaScript application frameworks are already moving in this direction and making it possible today.

The question, then, is what will those components look like? Will it be UI-first or code-first? Will it look like Ember, or Angular? Do Web Components have a future? These questions are hard to answer, so I say don’t bother.

At this point, you should look at building components within your specific framework / library of choice. Don’t wait for web components to become the standard before you dig in to components. Start today. Learn how to build smaller parts that can easily be orchestrated in to something larger.

The future of the web depends on component-based application development and architecture. And the web we have today is already seeing significant benefit from this approach.

Categories: Blogs

Yuval Yeret Opines on SAFe

Agile Product Owner - Wed, 08/26/2015 - 02:53

Yuval Yeret, CTO of Agile Sparks, and a thought leader with a strong presence in the Lean-Kanban community, recently opined about SAFe at His first post, What I like most about the Scaled Agile Framework, points out some interesting perspectives, including his appreciation for the ”train-the-whole-team-together quickstart” approach; one that is very effective in practice, and yet raises eyebrows in some camps.

In his second article, How I Would Improve SAFe to Make it Even Better, he shares his thoughts on how SAFe could be improved, providing specific input, some of which we will be addressing in the next version of SAFe. With respect to Kanban, folks can see the direction we are heading by visiting, where you will see Kanban integrated into all levels. He raises other interesting points as well.

We agree on both fronts. SAFe can be even better, so I better get back to work. There has to be another version around here somewhere.

Thanks for the input Yuval!

Categories: Blogs

Increasing Software Quality with Visual Management

Ben Linders - Tue, 08/25/2015 - 12:18
One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to do and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. This post provides ideas how you can do that. Continue reading →
Categories: Blogs

The Value of Using the Scaled Agile Framework (SAFe)

TV Agile - Tue, 08/25/2015 - 09:31
Dean Leffingwell, founder and CEO of Scaled Agile, discusses his new video, “Leading Scaled Agile Framework (SAFe) LiveLessons,” results that enterprises who adopt SAFe are seeing, the must-have SAFe practices, and the keys to successful enterprise adoption of SAFe. Watch this video on
Categories: Blogs

Kickstarter Idea: Mac OS X Package Manager

Developing on the Mac has generally been an awesome experience over the years especially with OS X and the UNIX underpinnings. The long pain point in this area is the lack of a solid supported package manager. It’s not in Apple’s DNA to worry about power users who actually use the terminal, and they’re unlikely to ever consider it important enough to delegate resources too. MacPorts and its hipster cousin Homebrew have been around for a while, but they’re always a bit rough around the edges, missing packages here and there, old versions, and sometimes they need extra tinkering just to install. In all it’s a most un-Mac like experience.

I don’t know that it will ever happen, but I know I’d support a Kickstarter that promised to maintain a Mac package manager like rpm or apt for OS X. I don’t care if they use Homebrew or Macports and just make it more robust, or build a new one from scratch. I’d just like a simple install of all those open source libraries. Yehuda Katz did a simple installer for Ruby and Rails on OS X a few years back via a Kickstarter, so I know there’s precedent and this would impact a lot more developers. Saving hassle is certainly worth some bucks for a kickstarter.

Categories: Blogs

Virtual Teams – Agile or Bust

A collaboration by David Grabel and Mario Moreira
You’ve just been given a plum assignment, heading up a major new application development project. Congratulations! Your boss just got off the phone with a large off-shore contracting firm.  At the labor prices they are quoting, we’ll save a fortune and come in under budget. He knows that you’ve been experimenting with virtual teams; it’s time to kick this into high gear and really cut our labor costs. DON’T DO IT!By the time you factor in the extra costs for travel, the high costs of the locally based support personnel (project managers, architects, etc.), the increased systems and telecommunications cost, the miscommunication caused by lack of face-to-face conversations, and the rewrites this will require, the cost savings will evaporate. They will never complete it on time and the missed revenue alone will eat up all of your savings.

There are good reasons to rely on virtual teams. Cost savings is not one of them. Real world constraints can make virtual teams unavoidable. Your company might have a liberal “work from home” policy. Your development centers could be scattered about a large campus, across the country or around the world. You may have a strong relationship with an off-shore development company that has delivered high quality software on time in the past. You might be partnering with a company from another state. All virtual teams are distributed, whether it’s a single member working from home or dozens of teams scattered around the world. Co-located teams will almost always be more efficient and effective than virtual or distributed teams. When virtual teams are unavoidable, the key to success is to Be Agile. If you follow the agile values and principles you can successfully deliver valuable working software, quickly, with high quality, even with virtual teams.  Let us explore how the Agile values and principles can be put into action to help with virtual teams.
  • Value people and interactions over processes and tools by enabling virtual and physical face-to-face conversations. If team members are in different time zones, encourage flexible hours and provide high quality video conferences for stand-ups and other ceremonies. Supplement the teams with collaboration tools. Bring the teams together periodically to learn each other’s business contexts, cultures, and individual needs. Virtual teams necessarily need to rely more on electronic tools like agile project managers and collaboration software. These tools help, but virtual teams need to nurture the interpersonal relationships that allow trust to develop. Trust within and across teams is vital to agile success.
  • Value working software over comprehensive documentation by writing stories about the users experience and by delivering small increments quickly based on those stories. The traditional wisdom has been that virtual teams require very detailed requirements and design documents. These heavyweight artifacts don’t exist on agile projects. Very detailed requirements create the illusion of completeness and accuracy. All those details about what they system shall do obscure the problems we are trying to solve
  • Value customer collaboration over contract negotiations by scheduling regular demos with customers to get their feedback and deepen the understanding of the business problems to be solved. This is more important than checking the boxes on a requirements document. This is a case where virtual meeting tools can bring remote teams and customers together even when they are physically apart.

The agile values and principles are the best guiding lights available today to make virtual teams work. If you have to use virtual teams, please consider using agile practices and staying true to the values and principles. 
Categories: Blogs

The System Shall...

I’m currently working with a client that is adopting agile, which really means there are people around that have done agile, but it’s not widespread nor is anyone on my particular project experienced with agile. As is common in these situations, I’ve gone through at different points to try to help them develop their agile mindset. My developers are well-versed in agile, but the client is acting as the product owner, so their understanding of agile is important to project success.
Before my team started development, the client started working on a “requirements document.” It’s full of statements like “The system shall allow the user to select a need by date” Now while each snippet can help provide information, the document as a whole is about impossible to digest in order to understand what we’re supposed to build. I’m going through the document and working with the client team to extract user stories. 

As I’m working with the client, I am also trying to build the agile mindset within them. Agile isn’t just about following a different process. It’s about thinking about what you’re doing, inspecting and adapting as you go. In order to do this effectively, you need to know the why behind your actions. Why are we writing user stories instead of requirements documents? Why do we work in short iterations? Understanding this will help them become more agile, even after my team and I leave...and maybe they'll no longer be writing "the system shall..."
Categories: Blogs