Skip to content

Feed aggregator

Why I Am Not A Change Agent

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 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

Trying out the Serenity BDD framework; a report

Xebia Blog - Fri, 08/28/2015 - 13:47

“Serenity, that feeling you know you can trust your tests.” Sounds great, but I was thinking of Firefly first when I heard the name ‘Serenity’. In this case, we are talking about a framework you can use to automate your tests.

The selling points of this framework are that it integrates your acceptance tests (BDD) with reporting and acts like living documentation. It can also integrate with JIRA and all that jazz. Hearing this, I wasn’t ‘wowed’ per se. There are many tools out there that can do that. But Serenity isn’t supporting just one approach. Although it is heavily favouring Webdriver/Selenium, you can also use JBehave, JUnit, Cucumber. That is really nice! 

Last weekend, at the Board of Agile Testers, we tried the framework with a couple of people. Our goal was to see if it’s really easy to set up, to see if the reports are useful and how easy it is to implement features. We used Serenity ‘Cucumber-style’ with Selenium/Webdriver (Java) and the Page Object Pattern.


It maybe goes a little too far to say a totally non-technical person could set up the framework, but it was pretty easy. Using your favorite IDE, all you had to do was import a Maven archetype (we used a demo project) and all the Serenity dependencies are downloaded for you. We would recommend using Java 7 at least, Java 6 gave us problems.

Using the tool

The demo project tests ran alright, but we noticed it was quite slow! The reason is probably that Serenity takes a screenshot at every step of your test. You can configure this setting, thankfully.

At the end of each test run, Serenity generates an HTML report. This report looks really good! You get a general overview and can click on each test step to see the screenshots. There is also a link to the requirements and you can see the ‘coverage’ of your tests. I’m guessing they mean functional coverage here, since we’re writing acceptance tests.

Serenity Report

Writing our own tests

After we got a little overview of the tool we started writing our own tests, using a Calculator as the System Under Test. The Serenity specific Page Object stuff comes with the Maven archetype so the IDE could help you implement the tests. We tried to do it in a little TDD cycle. Run the test, let it fail and let the output give you a hint on how to implement the step definitions. Beyond the step definition you had to use your Java skills to implement the actual tests.


The tool is pretty developer oriented, there’s no denying that. The IDE integration is very good in my opinion. With the Community IntelliJ edition you have all the plugins you need to speed up your workflow. The reporting is indeed the most beautiful I had seen, personally. Would we recommend changing your existing framework to Serenity? Unless your test reports are shit: no. There is in fact a small downside to using this framework; for now there are only about 15 people who actively contribute. You are of course allowed to join in, but it is a risk that there are only a small group of people actively improving it. If the support base grows, it will be a powerful framework for your automated tests and BDD cycle. For now, I'm going to play with the framework some more, because after using it for about 3 hours I think we only scratched the surface of its possibilities. 


Categories: Companies

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

Lean, Agile & Scrum Conference, Zurich, Switzerland, September 2 2015

Scrum Expert - Thu, 08/27/2015 - 10:00
The Zurich Lean, Agile & Scrum Conference (LAS) is a one day conference that focuses on Lean and Agile approaches for software development. The conference provides both German and English content. The keynotes of the of the Zurich Lean, Agile & Scrum Conference will be Ralf Westphal and Niklaus Brantschen. In the agenda you can find topics like “Agree or Disagree, but Commit”, “Facilitation Dojo”, “Process- and Team-Performance”, “Transforming your Culture with Working Agreements”, “Storytelling in a Technical World”. Web site: Location for the Zurich Lean, Agile & Scrum Conference: TECHNOPARK ...
Categories: Communities

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

Swisscom: Disrupting the TV Industry with Agile

Rally Agile Blog - Wed, 08/26/2015 - 16:00

Chances are, you or someone you know has “cut the cord” recently — canceled your cable TV subscription service in favor of the alternatives, like a set-top box, rabbit ears, streaming services such as Netflix and Hulu, or Internet-delivered media. Here in the United States, one survey found that more than eight percent of cable TV subscribers had cut the cord last year.

One thing you may not have considered is how this cord-cutting, multiplied by the thousands, is radically disrupting the cable and communications industry.

Swisscom, Switzerland’s leading telcomm company, was mindful of fast-changing industry trends when it decided to insource the development work for a new IPTV (Internet-delivered television) initiative. The company wanted to get its Swisscom TV 2.0 service out to the marketplace quickly, before its competitors; however, its organizational structure and culture were not set up for agile delivery.

Laying the Groundwork

Bringing the development work for the IPTV initiative in-house was just one of many steps the company took to transform itself: it also built strong, cross-functional trust and transparency by co-locating developers with business owners, DevOps, and vendors across near-shore teams in six countries. Much of this groundwork already was laid when the company discovered agile a few years ago.

“We simply did what made sense for us, and we figured it out as we went along. Only later did we realize that our efforts overlapped with existing practices for agile at scale.”

- Simon Berg, Agile Program Manager, IPTV Engineering

Scaling Up

With support from Swisscom’s head of TV development and technology, the IPTV group adopted and scaled agile approaches: it implemented the Scaled Agile Framework® (SAFe®) and took advantage of Rally Unlimited Edition’s performance in tracking work at the portfolio level.

“We chose the Rally platform for its portfolio-level management capabilities. No other solution could link strategy to execution across 12 teams, with rolled up visibility of multiple programs.”

- Simon Berg

Launch Time

Swisscom launched TV 2.0 in 2014, and in just over a year racked up more than half a million subscribers — that’s more than 15% of all Swiss households. Meanwhile, Swiss cable companies have lost 98,000 TV customers in the past 12 months.

Swisscom’s agile transformation played a key role in the initiative’s success. The company cut development cycles from 12 months down to 3-6 months, and the teams’ use of agile testing and validation approaches improved quality and minimized rework. Perhaps most importantly, Swisscom didn’t just deliver on-time: it delivered the right product for the market. Being agile allowed the company to respond to shifts in direction and keep up with fast-changing consumer demands.

“Ultimately, the culture and the people are how we innovate and win in an industry that is constantly being disrupted by new technologies.”

- Simon Berg

Read the entire Swisscom case study, then learn more about big room planning and Rally’s agile at scale platform.

Categories: Companies

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 fallacy and 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 you 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 direct, 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 components in 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 markdown 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

September 8, Experience report – Kanban

Agile Ottawa - Wed, 08/26/2015 - 06:59
1. What’s an “Experience Report”? A gathering where like-minded individuals share via short talks their success stories (or failure) and extract the source of that success (or failure). 2. How does this work? Interested participants will be given the opportunity to … Continue reading →
Categories: Communities

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

Agile Alliance Elects 2016 Board of Directors

Scrum Expert - Tue, 08/25/2015 - 21:34
Agile Alliance has announced that its membership has overwhelmingly approved the slate of candidates put forth for the 2016 Board of Directors. Results for the 2016 election were reported to the Agile Alliance membership by Board Secretary Shane Hastie at the annual membership meeting on August 5 during Agile2015, the organization’s annual North American conference held at the Gaylord National Hotel in National Harbor, Maryland. The Agile Alliance membership elected three members to the Board of Directors for three-year terms: Dr. Rebecca Parsons (USA), Paul Hammond (England), and Victor Hugo Germano ...
Categories: Communities

Scrum & Kanban with MantisBT

Scrum Expert - Tue, 08/25/2015 - 16:59
MantisBT is a popular open source bug tracker. Its architecture features a plugin system that allows extending its functionalities. This article lists the MantisBT plugins that allows to integrate an Agile project management approach like Scrum or Kanban around the basic features of MantisBT. There are currently four open source plugins that allows to add Scrum and Kanban features so that you can integrate an Agile project management approach with the basic functionalities of the MantisBT open source bug tracking tool. AgileMantis agileMantis tries to bridge the gap between the open source bug ...
Categories: Communities

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

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.