Skip to content

Feed aggregator

Intel Case Study: 8 Trains in 2 months

Agile Product Owner - Thu, 09/11/2014 - 21:34

At Agile Israel 2014 , SPC Yariv Weltsch-Cohen from Intel MDO presented  a case study which recaps their journey into lean-agile transformation using SAFe to launch their first Agile Release Trains.

Intel wanted to standardize the planning and execution process they used to deliver programs for testing and categorizing their chips on different platforms. Scrum was their mode of work for a few years, and SAFe gave them a way to scale up to a program level. They saw this as a natural next step in their lean-agile evolutionary ladder, and a way to accommodate big organizational change. Being Intel, they didn’t just dip their toe into the water. Within 2 months they successfully deployed 8 Agile Release Trains across different geographies. What’s not mentioned in the study, but is noteworthy, is that within another quarter the 8 ARTs became 12 ARTs (~1500 employees) supporting the entire Intel product line.

The 28-page briefing provides their basis for choosing SAFe, and some interesting Q1 release results and conclusions. A few highlights:

• 1st RP is A LOT of effort, afterwards gets much easier.

• Predictability on track for 80% goal

• RP using SAFe recipe helped highlight dependencies and risks (even showstoppers) far in advance of what they saw before.

• Business Owners should take full SAFe training

• Scrum of Scrums is a critical ceremony—based on number of dependencies and learning throughout the PI.

Many thanks to Intel’s Yariv Weltsch–Cohen for spearheading such an ambitious launch and for taking the time to capture their experience and share it with the rest of us.

You can download the study here.

Stay SAFe,

Categories: Blogs

Agile Cambridge, Cambridge, UK, October 1–3 2014

Scrum Expert - Thu, 09/11/2014 - 18:12
Agile Cambridge is a three-day conference that is focused on Agile software development. The conference mixes tutorials, experience reports and case studies. Some of the keynotes of the 2014 edition will be presented by Tom Gilb and Nat Pryce & Steve Freeman. In the agenda you can find topics like “Agile! The quick way to build stuff that nobody wants”, “Enterprise Agility: Strategies for Scaling Agile across the Organisation”, “Release Testing Is Risk Management Theatre”, “How to mix together XP and Scrum to enable self organized teams”, “Retrospective Anti-Patterns”, “A systemic ...
Categories: Communities

Ten at Ten Meetings

J.D. Meier's Blog - Thu, 09/11/2014 - 17:54

Ten at Ten are a very simple tool for helping teams stay focused, connected, and collaborate more effectively, the Agile way.

I’ve been leading distributed teams and v-teams for years.   I needed a simple way to keep everybody on the same page, expose issues, and help everybody on the team increase their awareness of results and progress, as well as unblock and breakthrough blocking issues.

Why Ten at Ten Meetings?

When people are remote, it’s easy to feel disconnected, and it’s easy to start to feel like different people are just a “black box” or “go dark.”

Ten at Ten Meetings have been my friend and have helped me help everybody on the team stay in sync and appreciate each other’s work, while finding better ways to team up on things, and drive to results, in a collaborative way.  I believe I started Ten at Ten Meetings back in 2003 (before that, I wasn’t as consistent … I think 2003 is where I realized a quick sync each day, keeps the “black box” away.)

Overview of Ten at Ten Meetings

I’ve written about Ten at Ten Meetings before in my posts on How To Lead High-Performance Distributed Teams, How I Use Agile Results, Interview on Timeboxing for HBR (Harvard Business Review), Agile Results Works for Teams and Leaders Too,  and 10 Free Leadership Tools for Work and Life, but I thought it would be helpful to summarize some of the key information at a glance.

Here is an overview of Ten at Ten Meetings:

This is one of my favorite tools for reducing email and administration overhead and getting everybody on the same page fast.  It's simply a stand-up meeting.  I tend to have them at 10:00, and I set a limit of 10 minutes.  This way people look forward to the meeting as a way to very quickly catch up with each other, and to stay on top of what's going on, and what's important.  The way it works is I go around the (virtual) room, and each person identifies what they got done yesterday, what they're getting done today, and any help they need.  It's a fast process, although it can take practice in the beginning.  When I first started, I had to get in the habit of hanging up on people if it went past 10 minutes.  People very quickly realized that the ten minute meeting was serious.  Also, as issues came up, if they weren't fast to solve on the fly and felt like a distraction, then we had to learn to take them offline.  Eventually, this helped build a case for a recurring team meeting where we could drill deeper into recurring issues or patterns, and focus on improving overall team effectiveness.

3 Steps for Ten at Ten Meetings

Here is more of a step-by-step approach:

  1. I schedule ten minutes for Monday through Thursday, at whatever time the team can agree to, but in the AM. (no meetings on Friday)
  2. During the meeting, we go around and ask three simple questions:  1)  What did you get done?  2) What are you getting done today? (focused on Three Wins), and 3) Where do you need help?
  3. We focus on the process (the 3 questions) and the timebox (10 minutes) so it’s a swift meeting with great results.   We put issues that need more drill-down or exploration into a “parking lot” for follow up.  We focus the meeting on status and clarity of the work, the progress, and the impediments.

You’d be surprised at how quickly people start to pay attention to what they’re working on and on what’s worth working on.  It also helps team members very quickly see each other’s impact and results.  It also helps people raise their bar, especially when they get to hear  and experience what good looks like from their peers.

Most importantly, it shines the light on little, incremental progress, and, if you didn’t already know, progress is the key to happiness in work and life.

You Might Also Like

10 Free Leadership Tools for Work and Life

How I Use Agile Results

How To Lead High-Performance Distributed Teams

Categories: Blogs

Agile Volunteering, Rally Style

Rally Agile Blog - Thu, 09/11/2014 - 17:00

Rally Onboarding Bootcamp: Class of June 2014

“Rally truly practices what it preaches. Volunteering at There With Care touched my heart and made me proud that the company I work for is helping such a wonderful organization. It was amazing how we pulled together as a team and incorporated our Agile training from earlier in the day into our give-back project.” — Terri Barrowcliff, Customer Relationship Manager, Rally Onboarding Bootcamp, June 2014

During my first year at Rally, we’ve experienced exciting growth as a company. When I started in August 2013, we had about 400 people worldwide. Today, we’re over 500 and still growing. With so many people joining the company, we’re continuously refining our onboarding process — adapting it to focus on what newcomers really need to know to succeed at Rally, and introducing a strong dose of company culture. Each month, new employees from around the globe come to our Boulder headquarters to experience Onboarding Bootcamp, Rally style.

Giving back to the communities in which we live and work is among the values on which Rally was founded and holds dear (see 1%: Small Percentage, BIG Impact). Another of our core values, as you might expect, is to Live Agile. So we challenged ourselves to combine the two: create an impactful community service activity that instills the importance of giving back our time and talents that’s also a hands-on learning opportunity in Agile practices. 

I reached out to Jodee Spalding, Volunteer Director at There With Care, a Boulder-based nonprofit organization that provides fundamental support services to families and children facing critical illness. I knew that There With Care relies heavily on volunteers to deliver its services and found a willing partner to customize a program for Rally. With Jodee’s help we quickly identified an important need that Rally could fulfill.

“Easy Meal Care Bags are essential to the parents and caregivers of children being treated in the hospital. Instead of leaving for meals, loved ones can stay at the child’s bedside to provide comfort and support, and ensure they don’t miss an opportunity to speak to the child’s doctor. Now that Rally is sending volunteers once a month to create the bags — and funding the cost — we are able to replenish them as needed, and the families are so grateful.” — Jodee Spalding, There With Care

On their first day of Rally Bootcamp, new employees spend two hours with our Agile coaches learning about Agile concepts, methodology, and practices. Later that afternoon at There With Care, we ask the new hires to practice some of those concepts — such as self-organizing teams, collaboration, and inspect/adapt — when assembling the Easy Meal Care Bags. We provide the product requirements and let the team decide how to get the job done, with the following guidance:

  • Take time to plan the work and organize as a team
  • Focus on quality and process, more than on quantity and speed
  • Limit work in progress (WiP) and watch out for bottlenecks
  • Respond to change over following a plan
  • Consult the Product Owner (Jodee) as much as needed
  • End with a retrospective — what did we learn and what could we do better next time?

Rally Bootcamp participants conduct a midpoint review while assembling Easy Meal Care Bags.

Since February, 134 employees have volunteered at There With Care, contributing a total of 201 hours and creating 425 Easy Meal Care Bags weighing in at 3,188 pounds of food and drinks — lovingly delivered to parents stationed at the bedsides of their critically ill children. A grant from the Rally For Impact Foundation covers the cost of the bag contents, which has totaled nearly $5,000 since the partnership started just nine months ago.

“Just as meaningful as the grant is Rally’s donation of more than 200 volunteer hours from new groups of big-hearted Rallyers lending their compassion each month. In appreciation, we’ve honored Rally with our Inspiration Award, presented to individuals and community partners that have contributed outstanding service to There With Care’s mission.” — Jodee Spalding, There With Care

Geri Mitchell-Brown
Categories: Companies

The Growing Agile monthly retrospective

Growing Agile - Thu, 09/11/2014 - 14:16

Every month we have a company retrospective for at least 90 minutes. In 3 years it has proven to be of huge value. Every month we get on the same page with our values, what we are doing, what we want to do, and how we are going to focus on one thing.

We are two people who pair work for about 95% of our time. We are always together and talk everyday. Despite that this meeting has become our treasure chest. We look forward to it. It energises us. Personally I can’t see how people don’t get value from Retrospectives. OK – perhaps they are poorly run, hopefully us blogging plans will help with that. If you have never experienced one, try this one. You can even do it alone, by yourself.

Here is this months retrospective plan:

GAretroplan The Growing Agile monthly retrospective

Categories: Companies

x-Banning a process

Improving projects with xProcess - Thu, 09/11/2014 - 13:15
I've just proposed an experience paper for LKUK14 - "x-Ban the process! (or how a product team is improving value delivery rate with Kanban)". Feel free to vote for it by the way here!

Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it!

When I was asked in early 2013 if I would work with Clearvision's product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I've reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn't Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter.

There are many lessons I've learned from this experience: some things that worked - and some that didn’t. They're lessons and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected when I started 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others.

Start x-Banning your process now!
Categories: Companies

Killing the Buddha

Agile Tools - Thu, 09/11/2014 - 08:41



“If you meet the Buddha on the road, kill him!”

This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes.

In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine our patterns of behavior deeply, we worship idols with bizarre names like “Kanban” and “Scrum” and fight (flame) wars over them. We anoint our priests as guardians of that process (yes, I’m talking about you, Scrum Masters), and agonize endlessly over whether we and others are following the right path.

Wow, maybe Agile actually is a religion. That’s pretty scary. I’ve got to go sit down now.

OK, I’m back. What were we talking about? Oh yeah, killing the Buddha. So, given my little digression above, it would be pretty easy to rewrite that old Zen saying like this:

“If you meet an Agile Guru while on your journey (to excellence, improvement, whatever), kill him!”

Now aside from sounding terribly violent, what the heck do I mean by that? It turns out, that having an Agile guru around is pretty limiting when it comes to learning and continuing to grow. Whenever we have a guru like that, what do we do? We defer to his expertise. We wait for him to provide the answer and we stall our own learning journey. Having an Agile guru around can freeze an organization’s development. You end up limited to whatever level the guru is at.


Many organizations have these characters lurking in their midst. Heck, I was one once. I still have a business card with a title of “Though Leader” emblazoned on it around somewhere. I’m here to tell you it can happen to anybody. One day you are a perfectly decent, self-respecting developer and then WHAM! you become an Agile Coach, or a Thought Leader, or a Lean Sensei, or any number of other wacky guru code names.

You become, THAT guy.

And trust me, you don’t want to be that guy. You know the one, the Agile guy? The guy who simply must render an Agile judgment every time he opens his mouth. The guy who everyone defers to when it comes to do all things Agile. To paraphrase the old Life cereal commercial “Is it Agile? Hey, let’s get Mikey. He’ll judge anything!”

…oh brother, I think I just dated myself straight back to the stone age.

So what do you do when you have an Agile guru? You get rid of him! What if YOU are the Agile guru? Now that’s awkward. Well, your mission is to eliminate that perception. How do you do that?

  1. Keep your mouth shut
  2. Stop telling people what’s Agile (see #1). Use pantomime or something instead.
  3. Bring in, find, unearth or otherwise manufacture someone who has more expertise than you do. Understand that by doing this, you will run the very real risk of learning something. Sorry.
  4. Rinse and repeat until nobody mentions Agile in your presence. Ever.

So if you find yourself or someone you love has become an Agile guru, take heart! There is a cure! The best thing you can do to avoid stifling (and annoying) everyone in your organization trying to get work done is kill the Buddha.

Filed under: Agile, Lean, Process, Scrum Tagged: Buddha, Kanban, Lean, mastery, Scrum, Sensei, Thought Leader
Categories: Blogs

Xcode 6 GM & Learning Swift (with the help of Xebia)

Xebia Blog - Thu, 09/11/2014 - 08:32

I guess re-iterating the announcements Apple did on Tuesday is not needed.

What is most interesting to me about everything that happened on Tuesday is the fact that iOS 8 now reached GM status and Apple sent the call to bring in your iOS 8 uploads to iTunes connect. iOS 8 is around the corner in about a week from now allowing some great new features to the platform and ... Swift.


I was thinking about putting together a list of excellent links about Swift. But obviously somebody has done that already
(And best of all, if you find/notice an epic Swift resource out there, submit a pull request to that REPO, or leave a comment on this blog post.)

If you are getting started, check out:
It's a Github repo filled with extra Playgrounds to learn Swift in a hands-on matter. It elaborates a bit further on the later chapters of the Swift language book.

But the best way to learn Swift I can come up with is to join Xebia for a day (or two) and attend one of our special purpose update training offers hosted by Daniel Steinberg on 6 and 7 november. More info on that:

Categories: Companies

Das Eis brechen – mit Stift, Papier und Visual Scrum

Scrum 4 You - Thu, 09/11/2014 - 07:45

Die beliebte Small-Talk-Frage: „Und was machst Du so beruflich?“ wird für Scrum Coaches, ScrumMaster und Consultants nicht selten zur Bewährungsprobe. „Ich bin ScrumMaster“ erzeugt in unwissenden, weil wenig technischen Berufsgruppen oft nur ein Stirnrunzeln und nicht weniger häufig ein müdes Lächeln ob des ulkigen Fremdwortes – auch gerne begleitet von der Frage, welchen Gürtel man denn da schon habe.
Und dann fängt es im Kopf an zu rattern: Wo fange ich jetzt mit der Erklärung an, bei Adam und Eva? Beim Rugby? Bei Nonaka, Sutherland und Schwaber? Egal, wofür man sich entscheidet, so wirklich trivial wird es selten. Und das obwohl Scrum nichts anderes macht, als die für die Produktentwicklung intuitiv richtigen Dinge in einen Rahmen zu packen und interdisziplinäre Teams in kurzen Zyklen gemeinsam an einer Lösung arbeiten zu lassen.

Hier verhält es sich mit Scrum wie mit jedem anderen Thema auf diesem Erdball: Wenn man nur tief genug drinsteckt, lässt sich der Grad der Komplexität nach Belieben erhöhen und ehe man sichs versieht, hat man die Zuhörer in den Schlaf begeistert. Und nicht nur im privaten Rahmen sind die Erklärungskünste des agilen Prozesshüters gefragt. Es liegt in der Natur seines Berufs, an den Schnittstellen der Scrum-Teams für ein gemeinsames Verständnis sorgen zu müssen und den Prozess weiter ins Unternehmen zu tragen.
Und damit ist es ja längst nicht getan. An dieser Stelle soll die Debatte darüber, ob ein erfolgreicher ScrumMaster technisches Verständnis haben muss oder nicht, nicht angefeuert werden. Fakt ist aber, dass ein Team nicht nur zwischenmenschliche Probleme aus der Welt schaffen muss, um das gemeinsame Ziel zu erreichen.

Wohl demjenigen, der es versteht, Stift und Papier in den Grundfunktionen zu bedienen: schreiben und skizzieren. Es ist kein Zufall, dass sich Boris Gloger Consulting und die Kommunikationslotsen zusammengetan haben, um Scrum Consulting und Visual Facilitation zu einem gemeinsamen Training zu verschmelzen. Für die Teilnehmer bedeutet das: Sie erlernen die bikablo® Grundtechnik und können sie direkt auf ihren Arbeitsalltag im agilen Umfeld anwenden.

Ein Schelm, wer glaubt, hier gehe es lediglich darum, schöne Flipcharts zu malen – getreu dem alten Politiker Schlachtruf „Inhalte überwinden“. Nein, hier geht es darum, sich, seine Teamkollegen, Kunden oder Stakeholder schnell und effektiv zu einem gemeinsamen Verständnis für eine Situation oder der Lösung eines Problems näher zu bringen.


Angenehmer Nebeneffekt: Wenn Sie das nächste Mal jemand fragt, was Sie eigentlich machen, malen Sie es einfach auf!

Tipp: Visualisieren wie ein Meister – mit den Tipps aus unserem Training “Visual Scrum” sind chaotische und inhaltsleere Flipcharts Schnee von gestern. Melden Sie sich hier gleich zum nächsten Termin am 13. & 14. Oktober 2014 in Köln an!

Related posts:

  1. Visual Scrum
  2. The five secrets of a successful Scrum training | May 22nd , Recife, Brazil
  3. Servant Leadership

Categories: Blogs

Adventures in Europe - Peter Hundermark - Wed, 09/10/2014 - 22:41

Denmark trainees

Shortly after joining Scrum Sense in February this year I started my journey to become a Certified Scrum Trainer (CST). The process includes co-training with other CSTs around the world, so that I can get feedback to improve and, once I am good enough, I can get their recommendations that are essential to acceptance. For the past week I have been lucky enough to travel around Europe and co-train with some of the top CSTs and CSCs (Certified Scrum Coaches) in Europe. It has been a wonderful experience for me.

My trip started in Copenhagen, where I spent a wonderful two days with Carsten Feilberg, a friend and an incredible tester. We spent time refining our workshop for Let’s Test Oz where we will be presenting on Communicating Complex Information in Sydney next Tuesday. We have been designing the workshop over mail and Skype for the past couple of months and being together once more re-enforced the Agile principle that face-to-face communication is the best kind. We have come up with a great design and I am really looking forward to our session.


CSM Aarhus with Bent Myllerup

My next stop was Aarhus also in Denmark. There I met up with Bent Myllerup, a very experienced CST and CSC with agile42. I spent two days co-training a public Certified Scrum Master (CSM) class with Bent in Denmark. Lucky for me the course was delivered in English. We had eight participants and received wonderful feedback. I was able to train some of the modules and learned some new techniques from Bent. I love being in a fresh context, because I can always learn new things and see how different people understand and take in information. It’s also interesting to see the European adoption of Agile, the different industries that are beginning to understand the value of empirical process control and fast feedback loops, and  working with teams instead of individuals. Bent speaks about a truck factor which I thought was a novel way of illustrating the point of resilience. The track factor is the number of people in a team that, if they were hit by a truck or won the lotto and left, the project would have to stop. So if you have only one key team member that knows everything and that information is not shared in some way with the team then you have a truck factor of one. A higher truck factor is better than a lower one. What is the truck factor of your teams?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

From Denmark I went to Berlin. Berlin is an amazing and crazy city. I arrived early on Saturday morning. Half of the city hadn’t woken up yet and the other half hadn’t been to bed. I was lucky enough to get to explore and see some of the sights. Sunday evening I met up with Andrea Tomasini, another very experienced and talented trainer and coach from agile42. We ran through our course plan for another CSM class on Monday and Tuesday. I got the opportunity to see Andrea in action and to train some of the course modules. I really enjoyed the way that both trainers focused not only on Scrum, but also on how important it is to be Agile. Transformation is difficult and changing your mindset early on is important. It’s also interesting to see how many companies both in South Africa and internationally have similar problems. We had 20 participants from all different backgrounds from gaming to building of aeroplanes. Who said Agile is just for software?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

It’s amazing to see how many different contexts are interested in the principles and values of Agile and Scrum, and how many people are really keen and eager to learn. The Training from the Back of The Room approach also helps to encourage people to learn on their own and creates an atmosphere of excitement and energy.

All in all it was an amazing experience. I had the opportunity to work with some great coaches and trainers and to learn new things that I can bring home. I love how supportive and encouraging our community is, both in South Africa and internationally. This is a long and tough journey and I feel that this trip has really helped to get me to the next level.

I am looking forward to co-training the next CSPO course in Johannesburg with Peter starting 30 September. Maybe I will see you there. If not I’ll be speaking at the Scrum Gathering in Cape Town in October, or maybe I will catch you at Let’s Test in Australia next week!

The post Adventures in Europe appeared first on ScrumSense.

Categories: Blogs

The Rules Have Changed

Sonar - Wed, 09/10/2014 - 22:34

If you’ve already taken a look at SonaQube 4.4, the title of this post wasn’t any news to you. The new version introduces two major changes to the way SonarQube presents data: the new rules space and the changes to the source viewer.

If you’ve been keeping up version to version, you’ve noticed new styling creeping in to the design. We formed a Web team this year to focus on transforming SonarQube’s interface into something as sexy as the underlying functionality, and the team is starting to hit its stride.

The new rules space is a reimagining of how to interact with rules. Previously, they were accessed only within the context of their inclusion (or not) in a single profile. Want to know if a given rule is present in multiple profiles? Previously, you had to hunker down because it could take a while.

Now rules have their own independent presentation, with multi-axis search.

All the search criteria from the old interface are still available, and several new ones have been added. The rule tags introduced in SonarQube 4.2 become searchable in 4.4, as do SQALE characteristics. And for most criteria you can search for multiple values. For example, it’s now easy to find rules in both “MyFirstProfile” and “MySecondProfile” simply by checking them both off in the profile dropdown.

Conversely, if you want to see all the profiles that include the rule “Unused method parameters should be removed”, simply pull it up in the search.

At the bottom of the rule listing, you’ll see all the profiles it’s included in, along with the severity and any parameters for the profile. If you’re an administrator, you’ll have controls here to change a rule in its current profiles and to add it to new profiles. The search results pane on the left also features bulk change operations for administrators, allowing them to toggle activation in a profile for all the rules in the search results.

It’s also easy now to find clone-able rules such as XPath and Architectural Constraint in Java; they’re called “templates” starting in 4.4, and they get their own search criterion.

I shouldn’t forget to mention the second tier below the search criteria. It represents the categories the search results span: languages, repositories, and tags, and the search results can be further filtered by clicking on the entries there. (A second click deselects and unfilters). For instance, here’s the default search filtered to show C rules that have been tagged for MISRA C++:

The point of this radical overhaul is to give you, the user, a better way to explore rules; to see what rules are available, which rules are used where, and which rules you might want to turn on or ask your administrator to turn on.

One interesting aspect of this is the new ability to explore rule activation across languages. For rules that are implemented directly within a plugin, as opposed to coming from 3rd party tools like FxCop or FindBugs, you’ll see that when the same rule is implemented in multiple languages, it usually has the same key (there are a few historical exceptions.)

So, for example, now you can easily see whether the same standards are being enforced across all languages in your organization.

The new rules space is just one piece of our new attitude toward data. Next time I’ll talk about the complete rework of the component viewer. It’s a reimagining that’s just as radical as this one.

Categories: Open Source

Cloud Changes the Game from Deployment to Adoption

J.D. Meier's Blog - Wed, 09/10/2014 - 17:22

Before the Cloud, there was a lot of focus on deployment, as if deployment was success. 

Once you shipped the project, it was time to move on to the next project.  And project success was measured in terms of “on time” and “on budget.”   If you could deploy things quickly, you were a super shipper.

Of course, what we learned was that if you simply throw things over the wall and hope they stick, it’s not very successful.

"If you build it" ... users don't always come.

It was easy to confuse shipping projects on time and on budget with business impact.  

But let's compound the problem. 

The Development Hump

The big hump of software development was the hump in the middle—A big development hump.  And that hump was followed by a big deployment hump (installing software, fixing issues, dealing with deployment hassles, etc.)

So not only were development cycles long, but deployment was tough, too.

Because development cycles were long, and deployment was so tough, it was easy to confuse effort for value.

Cloud Changes the Hump

Now, let's turn it around.

With the Cloud, deployment is simplified.  You can reach more users, and it's easier to scale.  And it's easier to be available 24x7.

Add Agile to the mix, and people ship smaller, more frequent releases.

So with smaller, more-frequent releases, and simpler deployment, some software teams have turned into shipping machines.

The Cloud shrinks the development and deployment humps.

So now the game is a lot more obvious.

Deployment doesn't mark the finish.  It starts the game.

The real game of software success is adoption.

The Adoption Hump is Where the Benefits Are

If you picture the old IT project hump, where there is a long development cycle in the middle, now it's shorter humps in the middle.

The big hump is now user adoption.

It’s not new.  It was always there.   But the adoption hump was hidden beyond the development and deployment humps, and simply written off as “Value Leakage.”

And if you made it over the first two humps, since most projects did not plan or design for adoption, or allocate any resources or time, adoption was mostly an afterthought.  

And so the value leaked.

But the adoption hump is where the business benefits are.   The ROI is sitting there, gathering dust, in our "pay-for-play" world.   The value is simply waiting to be released and unleashed. 

Software solutions are sitting idle waiting for somebody to realize the value.

Accelerate Value by Accelerating Adoption

All of the benefits to the business are locked up in that adoption hump.   All of the benefits around how users will work better, faster, or cheaper, or how you will change the customer interaction experience, or how back-office systems will be better, faster, cheaper ... they are all locked up in that adoption hump.

As I said before, the key to Value Realization is adoption.  

So if you want to realize more value, drive more user adoption. 

And if you want to accelerate value, then accelerate user adoption.

In Essence …

In a Cloud world, the original humps of design, development, and deployment shrink.   But it’s not just time and effort that shrink.  Costs shrink, too.   With online platforms to build on (Infrastructure as a Service, Platforms as a Service, and Software as a Service), you don’t have to start from scratch or roll your own.   And if you adopt a configure before customize mindset, you can further reduce your costs of design and development.

Architecture moves up the stack from basic building blocks to composition.

And adoption is where the action is.  

What was the afterthought in the last generation of solutions, is now front and center. 

In the new world, adoption is a planned spend, and it’s core to the success of the planned value delivery.

If you want to win the game, think “Adoption-First.”

You Might Also Like

Continuous Value Delivery the Agile Way

How Can Enterprise Architects Drive Business Value the Agile Way?

How To Use Personas and Scenarios to Drive Adoption and Realize Value

Categories: Blogs

Planning Feedback: Don’t Panic!

Agile Tools - Wed, 09/10/2014 - 08:31

Ring the Alarm

So the other day a VP asked our team for an estimate on a project. Now, putting aside whatever feelings you may have about the usefulness of estimates, we did a little planning, a little investigating, a little debating, and came up with an estimate for the project. I brought the estimate back to the VP and then the fireworks began. Apparently he had been thinking of a different number than we had given him. He wanted it done in half the time that we had forecast.


Now at this point in the story a lot of teams will panic and come back with one of two reactions:

  1. Fight – “We can’t do that! That’s not Agile” (or some variation on that tired theme)
  2. Cave – “We have no choice…”

But wait a second, there is a middle path. You can agree, but ask what can be compromised in terms of scope or other project constraints. You see, a new project is not just a learning process for you. Its also  learning process for the customer too. When  you get that first feedback, DON’T PANIC!

There is one important part of the planning process that I often see get lost: iteration. Doing a single round of planning and then presenting it to your customer as “Take it or leave it” isn’t what I’d call much of a dialog.

What we should be doing is some lightweight planning then review with the customer. “That’s horrible!” They cry, and then you say, “So what number were you thinking of?” And they return with something totally preposterous. OK, that’s cool. “Is there functionality we can drop to hit that date?”


Of course not. So you go back, you scratch your head, cut out all the fluff you can find…and you still are way off the desired estimate. So then you take it back to them and say, “Hey look, I know this isn’t what you wanted, but here is the ABSOLUTE minimum we can get away with.” At which point, the customer looks at you with a tear in their eye and says these magic words, “What CAN you give me?”

Now you have a real negotiation! It may not always play out this way, but hopefully you get the point. You can’t freak out when they give you that first reaction. Stay cool – this is the first time they’ve had to test their fantasies against your capabilities. They need to learn too. So give your stakeholders a chance to work together with you on figuring out just what is possible. Negotiate. The more iterations you go through, the better your chances of coming to an agreement that everyone agrees is the best.

Filed under: Agile, Process Tagged: Agile, estimates, estimation, executives, Feedback, panic, Planning, stakeholders
Categories: Blogs

Say Why to Estimates

Bobtuse Bobservations - Bob MacNeal - Wed, 09/10/2014 - 05:33
Agile estimation surfaces a clash of cultures. Broadly speaking the Agile community consists of makers & managers. The clash between makers & managers distills to motivation: Why &...

Bobtuse can be wildly informative
Categories: Blogs

The Battle of the Agile Curmudgeons? Forbes on SAFe

Agile Product Owner - Wed, 09/10/2014 - 00:39

Hi folks,

Forbes was agile enough to interview me and publish this article on SAFe in less than a week! Thanks to Jason Bloomberg, who specializes on covering digital transformation in the enterprise, for this balanced article on SAFe and its role and reception within the Agile community. He briefly describes the history of Agile methodologies, as well as both the benefits and criticisms of SAFe, including a viewpoint from Ron Jeffries, a SAFe critic and one of the creators of XP. Bloomberg reached some interesting conclusions—based on facts, numbers, case studies—that makes this article worth the read for anyone considering or involved in a lean–agile transformation.

So in the battle between “Agile curmudgeons,” Forbes says, “the proof is in the pudding.” I couldn’t agree more. In the end, it’s the business results that matter. That is always our focus.

Stay SAFe,

P.S. Those who know me know I’m not a curmudgeon, so he must have been referring to someone else.

Categories: Blogs

Tackling cross-cutting concerns with a mediator pipeline

Jimmy Bogard - Tue, 09/09/2014 - 18:17

Originally posted on the Skills Matter website

In most of the projects I’ve worked on in the last several years, I’ve put in place a mediator to manage the delivery of messages to handlers. I’ve covered the motivation behind such a pattern in the past, where it works well and where it doesn’t.

One of the advantages behind the mediator pattern is that it allows the application code to define a pipeline of activities for requests, as opposed to embedding this pipeline in other frameworks such as Rails, node.js, ASP.NET Web API and so on. These frameworks have many other concerns going on besides the very simple “one model in, one model out” pattern that so greatly simplifies conceptualizing the system and realizing more powerful patterns.

As a review, a mediator encapsulates how a series of objects interact. Our mediator looks like:

public interface IMediator
    TResponse Send<TResponse>(IRequest<TResponse> request);
    Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request);
    void Publish<TNotification>(TNotification notification) where TNotification : INotification;
    Task PublishAsync<TNotification>(TNotification notification) where TNotification : IAsyncNotification;

This is from a simple library (MediatR) I created (and borrowed heavily from others) that enables basic message passing. It facilitates loose coupling between how a series of objects interact. And like many OO patterns, it exists because of missing features in the language. In other functional languages, passing messages to handlers is accomplished with features like pattern matching.

Our handler interface represents the ability to take an input, perform work, and return some output:

public interface IRequestHandler<in TRequest, out TResponse>
    where TRequest : IRequest<TResponse>
    TResponse Handle(TRequest message);

With this simple pattern, we encapsulate the work being done to transform input to output in a single method. Any complexities around this work are encapsulated, and any refactorings are isolated to this one method. As systems become more complex, isolating side-effects becomes critical for maintaining overall speed of delivery and minimizing risk.

We still have the need for cross-cutting concerns, and we’d rather not pollute our handlers with this work.

These surrounding behaviors become implementations of the decorator pattern. Since we have a uniform interface of inputs and outputs, building decorators around cross-cutting concerns becomes trivial.

Pre- and post-request handlers

One common request I see is to do work on the requests coming in, or post-process the request on the way out. We can define some interfaces around this:

public interface IPreRequestHandler<in TRequest> {
    void Handle(TRequest request);

public interface IPostRequestHandler<in TRequest, in TResponse> {
    void Handle(TRequest request, TResponse response);

With this, we can modify inputs before they arrive to the main handler or modify responses on the way out.

In order to execute these handlers, we just need to define a decorator around our main handler:

public class MediatorPipeline<TRequest, TResponse> 
    : IRequestHandler<TRequest, TResponse> 
    where TRequest : IRequest<TResponse> {

    private readonly IRequestHandler<TRequest, TResponse> _inner;
    private readonly IPreRequestHandler<TRequest>[] _preRequestHandlers;
    private readonly IPostRequestHandler<TRequest, TResponse>[] _postRequestHandlers;

    public MediatorPipeline(
        IRequestHandler<TRequest, TResponse> inner,
        IPreRequestHandler<TRequest>[] preRequestHandlers,
        IPostRequestHandler<TRequest, TResponse>[] postRequestHandlers
        ) {
        _inner = inner;
        _preRequestHandlers = preRequestHandlers;
        _postRequestHandlers = postRequestHandlers;

    public TResponse Handle(TRequest message) {

        foreach (var preRequestHandler in _preRequestHandlers) {

        var result = _inner.Handle(message);

        foreach (var postRequestHandler in _postRequestHandlers) {
            postRequestHandler.Handle(message, result);

        return result;

And if we’re using a modern IoC container (StructureMap in this case), registering our decorator is as simple as:

cfg.For(typeof (IRequestHandler<,>))
   .DecorateAllWith(typeof (MediatorPipeline<,>));

When our mediator builds out the handler, it delegates to our container to do so. Our container builds the inner handler, then surrounds the handler with additional work. If this seems familiar, many modern web frameworks like koa include a similar construct using continuation passing to define a pipeline for requests. However, since our pipeline is defined in our application layer, we don’t have to deal with things like HTTP headers, content negotiation and so on.


Most validation frameworks I use validate against a type, whether it’s validation with attributes or delegated validation to a handler. With Fluent Validation, we get a very simple interface representing validating an input:

public interface IValidator<in T> {
    ValidationResult Validate(T instance);

Fluent Validation defines base classes for validators for a variety of scenarios:

public class CreateCustomerValidator: AbstractValidator<CreateCustomer> {
  public CreateCustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");

  private bool BeAValidPostcode(string postcode) {
    // custom postcode validating logic goes here

We can then plug our validation to the pipeline as occurring before the main work to be done:

public class ValidatorHandler<TRequest, TResponse>
    : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest<TResponse> {

    private readonly IRequestHandler<TRequest, TResponse> _inner;
    private readonly IValidator<TRequest>[] _validators;
    public ValidatorHandler(IRequestHandler<TRequest, TResponse> inner,
        IValidator<TRequest>[] validators) {
        _inner = inner;
        _validators = validators;

   public TResponse Handle(TRequest request) {
        var context = new ValidationContext(message);

        var failures = _validators
            .Select(v => v.Validate(context))
            .SelectMany(result => result.Errors)
            .Where(f => f != null)

        if (failures.Any()) 
            throw new ValidationException(failures);

        return _inner.Handle(request);

In our validation handler, we perform validation against Fluent Validation by loading up all of the matching validators. Because we have generic variance in C#, we can rely on the container to inject all validators for all matching types (base classes and interfaces). Having validators around messages means we can remove validation from our entities, and into contextual actions from a task-oriented UI.

Framework-less pipeline

We can now push a number of concerns into our application code instead of embedded as framework extensions. This includes things like:

  • Validation
  • Pre/post processing
  • Authorization
  • Logging
  • Auditing
  • Event dispatching
  • Notifications
  • Unit of work/transactions

Pretty much anything you’d consider to use a Filter in ASP.NET or Rails that’s more concerned with application-level behavior and not framework/transport specific concerns would work as a decorator in our handlers.

Once we have this approach set up, we can define our application pipeline as a series of decorators around handlers:

var handlerType = cfg.For(typeof (IRequestHandler<,>));

handlerType.DecorateAllWith(typeof (LoggingHandler<,>));
handlerType.DecorateAllWith(typeof (AuthorizationHandler<,>));
handlerType.DecorateAllWith(typeof (ValidatorHandler<,>));
handlerType.DecorateAllWith(typeof (PipelineHandler<,>));

Since this code is not dependent on frameworks or HTTP requests, it’s easy for us to build up a request, send it through the pipeline, and verify a response:

var handler = container.GetInstance<IHandler<CreateCustomer>>();

var request = new CreateCustomer {
    Name = "Bob"

var response = handler.Handle(request);


Or if we just want one handler, we can test that one implementation in isolation, it’s really up to us.

By focusing on a uniform interface of one model in, one model out, we can define a series of patterns on top of that single interface for a variety of cross-cutting concerns. Our behaviors become less coupled on a framework and more focused on the real work being done.

All of this would be a bit easier if the underlying language supported this behavior. Since many don’t, we rely instead of translating these functional paradigms to OO patterns with IoC containers containing our glue.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Agile Metrics

Scrum Expert - Tue, 09/09/2014 - 17:54
“You can’t manage what you don’t measure” is an adage that is popular in project management. However, metrics programs are not easy to implement and have their dark sides. In their book “The Agile Culture: Leading through Trust and Ownership”, Pollyanna Pixton, Paul Gibson and Niel Nickolaisen provides some advice about implementing metrics, the Agile way. How do we make sure that the metrics we are using are effective and not just vehicles for giving leaders a feeling of power and control while not achieving anything useful? How do we know ...
Categories: Communities

Decorating A Backbone.Model With Features, For A UI Component

Derick Bailey - new ThoughtStream - Tue, 09/09/2014 - 17:01

I’m a huge fan of component based UI development – the idea of having individual functional things in a UI be an encapsulated “component”. Have a search form? That’s a component. The search results? A separate component. That menu system? You guessed it… a component. There are a lot of benefits to doing things this way. But there are also a lot of challenges to doing things this way. One of those challenges is adding functionality to a model that is shared between components, when only one of those components needs that functionality.

If a single UI component needs to add functionality to a model, but no other component needs that functionality, you shouldn’t be adding that code to the shared model. Heading down that path leads to far too many concerns in the model. You’ll end up with multiple chunks of code potentially in conflict, doing similar things slightly differently, all to make different UI components and behaviors happy. 

Fortunately, there’s an easy solution to this problem (especially easy in JavaScript), the decorator pattern (from Wikipedia):

In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects

Interior decorator pattern

(yes, that’s an “interior decorator”, decorating code :D)

Decorating With A Memento

In my current client project, I have to load up a model and allow it to be edited. Once edits are done they can be saved back to the server. When edits are incomplete, or when the user realizes they don’t want the edits, a cancel button can roll back the changes and close the form without saving anything. This is a problem I solved a long time ago with the Backbone.Memento plugin.

As I said above, I don’t want to include the memento features in the model directly. I want to decorate the model with the memento features only within the “edit” UI component. This will give me the ability to save / rollback the changes in the model, but also keep that save / rollback code isolated to the edit form – no other code in my app will know about this ability, and my model will stay clean and clear of this code. 

It starts with a simple model:

Next, up I have a View and a function to decorate my model with the Memento functionality.

When the view is instantiated, I apply the decorator to the model and tell the view to hang on to the decorated object. 

Now my view can correctly use the Memento methods associated with the cancel button. When someone clicks save, the changes are left in place and the view is closed. But when someone clicks cancel, the changes are rolled back.

Because this View is using a decorator to get the Memento in place, no other code has access to the Memento methods. Any code that uses the model before or after the edit view has been shown, will only have the standard model methods available. 

Sometimes The Right Thing, Not Always

This technique is tremendously useful for more than just save / cancel functionality, too. It’s quite common for validation to be UI specific, for example. One UI will have a model that needs 2 or 3 fields, the next UI will have the same model but need 2 or 3 different fields, etc. Or there may be two very unrelated UI views that both use the same model based on simple variations (admin vs non-admin user, for example). In these cases, validation is going to be specific to the UI and not generic to the model. A decorator can easily add the correct validation code to the model, for the specific view.

While the decorator pattern is useful when you need to isolate behavior, it is not always the right thing to do. Sometimes the behavior really should exist inside of the model (or whatever the object is). When dealing with behavior that is specific to a UI, though, a decorator is a great way to add behavior as needed and not have to think about it in any other context.

     Related Stories 
Categories: Blogs

Acceptance Criteria

Leading Agile - Mike Cottmeyer - Tue, 09/09/2014 - 16:47
Acceptance Criteria Did We Build the Right Product? And, Did We Build the Product Right?

Acceptance criteria are an important yet, in my experience, often overlooked or undervalued aspect of the iterative planning process. Acceptance criteria are super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceived acceptance criteria. When we clearly define acceptance criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction.  In other words we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?

What are Acceptance Criteria?

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.

We’re not talking about horsheoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.

When are Acceptance Criteria defined?

A trap that I encourage my teams to avoid is writing acceptance criteria after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations. If we write and review acceptance criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.

What makes good Acceptance Criteria?

Acceptance criteria define when a work item is completed and working as expected. Acceptance Criteria should be expressed clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they  will be taking our acceptance criteria and translating them into automated test cases to run as part of our continuous integration build.

What. Not how.

Another trap that I coach my teams to avoid is ‘The how trap.’ Acceptance Criteria should state intent, but not a solution (e.g., “A user can approve or reject an invoice” rather than “A user can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT is expected, and not HOW the functionality will be implemented.

Acceptance Criteria Formats

The Given/When/Then format is helpful way to specify acceptance criteria:

Given some precondition When I do some action Then I expect some result

When we write acceptance criteria in this format, it not only provides a consistent structure, but we are also helping testers determine when to begin and end testing for that specific work item.

Sometimes it’s difficult to construct acceptance criteria using the given, when, then, format. Particularly when dealing with system level user stories. In those cases, I’ve found that using a verification checklist works well.

Another advantage to Verification checklists is that they are also simple to individually mark as complete as we implement functionality.

What are some of the challenges or techniques you’ve found when writing acceptance criteria?

The post Acceptance Criteria appeared first on LeadingAgile.

Categories: Blogs

Agile Manifesto and Enterprise – Rant and Rave (Session Proposal)

Learn more about our Scrum and Agile training sessions on

I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“.  The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session.  If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Knowledge Sharing

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