Skip to content

Feed aggregator

Minimum Viable Estimate

Agile Artisans - Thu, 12/04/2014 - 02:00

As teams adopt more responsive software practices, one area is often left behind. We believe that the development team should deliver functionality incrementally. We know about minimum viable products. But, especially in larger companies, we hold onto the requirements until they are "done" or "right". Well-intentioned requirements groups work months getting work lined up for the developers and testers.

First, requirements, when done well, are an ever-evolving view of the product and the customer's needs. Trying to get it right in one go is like trying to ship your product in one pass. It's difficult to make anything perfect, especially requirements. The law of diminishing returns (and Little's law) kick in quickly. In other words, it's just not worth it. You'll spend far more money, and lose development runway time, by trying to perfect requirements.

I'd like to suggest we start thinking in t

Categories: Companies

Opposite Views of a Product Roadmap

Tyner Blain - Scott Sehlhorst - Wed, 12/03/2014 - 20:22

Spinning cat optical illusion - different people see it spinning in opposite directions, some people can switch

Your product roadmap is a view of what you are building right now, in the near future, and in the more distant future.  Or is your roadmap a view of why you are building whatever you’re building right now, in the near future, and in the more distant future?

Your roadmap is both – but one is more important than the other – and product managers need to be able to view the roadmap both ways.

When you view the spinning cat animation(1) above, you will either see it as rotating clockwise or counter-clockwise.  Everyone has a default.  Because of bi-stable perception, the direction of rotation may reverse for you, but reversing direction is apparently more difficult for some people than others.

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways. I also hope to make the case that one view is more important than the other.

What the Team Will Be Building

Janna Bastow wrote an excellent article about the importance of flexibility in roadmaps.  The article provides a really good explanation of how product management is not project management, and the evils of having a roadmap which is nothing more than a “glorified Gantt chart.”

She provides a great visual depiction of rolling-wave planning.

visual of rolling-wave planning [larger image available in Janna’s article]

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future.  This is because –  from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future.  [ BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.]

The article provides very good explanations about the need for flexibility both in terms of time and scope within a roadmap.  Shifting the delivery of something to an earlier or time frame, or alternately thinking about a particular time frame including more or less deliverable.  This is however, only a “good explanation” when you’re thinking from the point of view of what the team will be building.

The key attributes of a product roadmap from this view are that descriptions of what to do are precise right now, less specific in the near term, and very flexible in the future. While I completely agree – given a focus on what is being built – I don’t think about product roadmaps in this way.  I believe my thinking has shifted because I’m primarily creating roadmaps, not consuming them.


A concept which may help you shift to thinking about a product roadmap in terms of why the team will be building is intentionality. There is a reason why you’re building something.

Your team is building features because they are trying to build solutions. More precisely, your team is building a product with a set of capabilities, which you hope your customers will choose (and use) to help with solving their problems.

Customers are trying to solve problems, they aren’t trying to use features.

As a product manager, your perspective needs to be rooted in the perspective of the problems your customers are trying to solve – the intent driving your roadmap – not the things your team is building in order to solve the problem.

Why the Team Will Be Building

Where the view of what to build gets fuzzier as you move from the present to the future, the view of why you build gets clearer as you move from the present to the future.  This is the exact opposite of rolling-wave planning, and that’s not only fine, it is good.

Choosing a particular group of customers (or market) to serve is a strategic decision. Generally this will not change, and when it does it will not be frequent. This is a long term view – the future for the team will involve building things to support this group of customers.  There is great and powerful clarity here – specifically about the future.  “We are, and will be, building to support customer group X.”

Given the decision to provide value for a specific group of customers, the logical next question is “how?”  To avoid ambiguity, the question is really “which of the problems our target customer faces are we going to help them solve?”  The charter for a product team can be described as “Help [a specific set of] customers solve [a specific set of] problems.”

In the near-term, there is flexibility in the choice of which problem to address next.  Having that flexibility is imperative, because discovery (from feedback from customers) tells us if we’ve got the right problems, in the right sequence.  So we need to be able to re-prioritize, and add or remove from the list of problems as we manage our roadmaps thematically.

In the “right now” the team is testing hypotheses.  Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help.  That hypothesis is a design.  The design may or may not be a good one.  The implementation of the design may be great, adequate, failing, or incomplete.  In this time horizon, the activities of the team building the product are concrete – build, test, learn.

These activities are much hazier from the perspective of why the team is building something.  Technically, there is still clarity about the customer and the problem (they aren’t changing).  However, there’s additional explanation required – a description of the hypothesis – to explain why a particular activity is being managed for the current sprint or release.  As an example

“We found that forcing users to make decision (X) when solving problem (Y) caused those users to abandon our product.  Based on interviews we’re defaulting decision (X), and we believe this will reduce abandonment by (Z%).”

The need for explanation about the specific “what” is how I interpret the reduced clarity about the near term, when focusing on why versus what.

I selected the spinning cat image because both points of view are valid.  From one point of view, all of the clarity occurs in the immediate term, and from the other point of view, all of the clarity manifests in the longer-term big picture.  Most people first see the cat spinning in the same direction, and most of the time product managers should seef their roadmap “customer first.”

A product manager has to be able to switch between both views – and communicate in either framework – depending on the context of what they are doing in the moment.  Building the roadmap is working backwards from the customer to the feature.  Helping the team execute, and appreciate the context and relevance of what they are working on involves going from the current deliverables up to the intent for building them.

Frequency of Change from Learning

Another reason I work “outside in” in my thinking about roadmaps is the frequency of change which comes from what we learn as we engage with our market, study our competitors, and adapt to industry changes.

Significant and sustained* feedback is needed to tell us we have chosen the wrong customers. How we choose customers is a topic for another article.  When I hear about companies pivoting, I think of it as picking different customers.

We start out engaging customers with a hypothesis that they will pay us to help them address a particular set of problems.  We start this process with a point of view of the relative priority of solving each problem.  Feedback from customers – throughout the product creation process – helps us improve this list of problems.  All within the stable context of helping a particular customer group solve their problems. Processes like the structured conversation from Discover to Deliver include these activities as part of the overall product creation process.

While working with customers, we find out what it means to satisfice.  We also develop and refine our understanding of the nature of the problems using tools like Kano analysis.  We also have the opportunity to discover when a particular design does not achieve the goal of helping the customer, or when a poor implementation fails to achieve the vision of the designer.  Sometimes, when stories are split to fit within a sprint, the smaller stories don’t actually solve the problem, and additional splits need to be completed before moving forward.

*This assumes we did not make colossally bad choices to begin with – opening us up to the debate between rationality and empiricism.  Bad choices may be discovered immediately.

Communication and Conclusion

Executives (should) want to talk about intent and strategy for investment in the product. Base your conversations on this.  If they need status report type updates about the activities of the team, then talk about features.  But try and shift the conversation back to corporate goals, strategy, and the role your product is intended to fill.

Other interested stakeholders will almost always ask about features.  This is perfectly understandable – they are not product managers, and they are focused on the wrong things.  They are focused on problem manifestations, not problems. Help them refocus while you address their concerns.

Product managers should drive roadmaps based on “why” not “what.”  We still need to be able to think in the opposite direction, but that approach should be secondary.


(1) Thanks Pech-Misfortune for the original animated image.

Categories: Blogs

A Kanban Canvas Example

AvailAgility - Karl Scotland - Wed, 12/03/2014 - 12:52

I’ve been doing the rounds of conferences and meet-ups recently, introducing the Kanban Canvas as a way of becoming a learning organisation. One of the more common requests and pieces of feedback is that an example would be useful. I have mixed feelings about this. On the one hand, giving an example feels like a slippery slope to giving a solution, and brings with it he risk of unconsciously narrowing the field of vision when looking for new answers. On the other hand, its come up often enough not to ignore!

I’ve decided put together a very simple example. Hopefully too simple, and simplistic, to be copyable, but concrete enough to help show how the canvas could be used. Its based on the experience from when I introduced a kanban system at Yahoo! I have taken some liberties in putting it together to keep it understandable – we didn’t formally use this approach, and it was a long time ago!

Click on the image to see a larger version. I have added some commentary about the different elements below.

en_Kanban Canvas v1-0 example


I have described the systemic challenge using the Pixar Pitch format (deferring the ‘Until finally’ to be covered by Impacts). It could be summarised by the the headline “Busy, Not Productive

Once upon a time a team was developing websites using Scrum

Every Sprint the team would struggle to agree with the PO on what they could deliver, and as a result they delivered very little.

One Sprint the team started trying to define smaller stories in more detail up front.

Because of that planning meetings became painfully long, and even less was delivered.

Because of that we tried a kanban system.


There is a single utopian and dystopian future for each Impact, using colour to differentiate. Utopian positive (+ve) impacts are green. Dystopian negative (-ve) impacts are red.


These are related to being able to release functionality early and often

  • +ve: Continuous deployments of new functionality
  • -ve: Websites broken, out of date and shut down

These are related to being a stable and high performing team

  • +ve: People clamouring to be on the team
  • -ve: Massive team turnover. No-one able to make changes.

These are related to being able to build the best product

  • +ve: Award winning websites, putting competition out of business.
  • -ve: No page views or visitors. Ridiculed on social media.
Interventions Study

We identified 3 types of work; defects in production, enhancements to released functionality, and new features. These were generally equated to small, medium and large pieces of work.

We were following a basic Scrum workflow of Backlog, In Process, and Done.


To share the work type, we used token size. Defects were on small index cards, enhancements on medium, and features on large. Additionally, token colour differentiated failure and value demand. Defects were on red cards, whilst the others were on green cards.

To share the status of work in process, we used token placement in a matrix to represent progress and quality. The horizontal placement showed progress, while the vertical placement showed quality. Thus a token in the lower right corner was nearly finished, but with unsatisfactory quality.

Completed work was kept visible by keeping its token placement in a Done column until then end of a quarter.


We replaced the backlog with a limited “Ready Queue” to help clarity on what the next priorities were. (This queue would be restocked every week).

Work in Process was limited by work type, focussing on only 1 feature and 2 enhancements at a time. Defects were not limited, but the goal was always to eliminate defects rather than optimise them. Additionally, there was a “Top 5” work items to focus on, which could be of any work type. (We had 5 “star” adornments as token inscriptions to share what the top 5 were).

The goal was to get work into production, so our Definition of Done policy was simply that work must also be approved by the UX, QA and Ops teams and actually deployed and available.


The primary desired impact was Flow, with an outcome of improved productivity being a indicator. This was quantified by measuring throughput of items per week, with an increase being the goal.

A risk, however, was that cutting quality, or optimising for defects, could be a negative consequence of focussing on throughput. This would badly impact both Value and Potential. Thus a count of live defects was also measured, with a decrease being the goal.

The traditional scrum cadences were de-coupled with a new set of cadences put in place:

  • Weekly scheduling meetings to restock the ready queue
  • Planning meetings on-demand when work actually starts
  • Fortnightly review meetings to check progress
  • Monthly retrospective meetings to insect and adapt the process

While experiments were not formally run, there were essentially 2 hypothesis being tested. The first was related to the board design, visualising and focussing on the work types. The second was related to the de-coupled cadences, with work flowing across them.

Wrapping Up

I hope this example shows how the canvas can be used to tell a simple story about what the elements of a process are (the interventions), their context (the system), and their goal (the impacts).

If you’d like to use the canvas, please download it. And if you’d like me to facilitate a workshop which uses the canvas to design your kanban system, then please let me know.

Categories: Blogs

Time To Up The Accountability Of Your Agile Teams

Leading Agile - Mike Cottmeyer - Wed, 12/03/2014 - 12:23

Time To Up The Accountability Of Your Agile Teams

In my last entry, I talked a bit about what accountability means to me. Check it out to create a shared understanding between us before reading on…

In this continuation, I will begin to dive into structures that support accountability at scale. For now, there seems to be enough material at the scrum team level and then subsequently at the scaled level. Here’s the delivery team level for ya.


Most of the companies I have worked with in the past several years are in the small (multi-millions) to very large (multi-billion) dollar range. Complexity, maturity, and age of the organizations were all drastically different. One of the steps I need in order to move the accountability needle forward in these organizations is the formation of teams. That’s the start of my scale. Good delivery teams.

More and more I am demanding that teams be an encapsulated cross-functional group of people with a purpose. It just works. I don’t need or want parts of people or percentage utilization… we do, in fact, need the whole person to make a whole team.

So what am I after with regard to accountability?

Most orgs I work with don’t have a great sense of accountability. The culture is all wrong to ask a developer to suddenly care about a product or capability. My approach to culture is to enable it to emerge. Ultimately, I’ll ensure the team is encapsulated and can be accountable for producing working, tested product.  It I don’t do that, a culture of responsibility won’t stand a chance.

Encapsulating the Team

By encapsulating a cross-functional team, I am enabling a more robust culture to emerge. I am able to hold the team accountable for the outcomes they generate. Given that my primary focus for scrum teams is to make and meet commitments that deliver working, tested product, holding them accountable for making and meeting commitments enables me to focus in on guiding the culture of the team toward a shared responsibility. Retrospectives become more meaningful as responsibility grows. This is the basis for my prototypical scrum team. A no-excuses team that owns their commitment and get’s better over time.

What is holding teams back from a responsible state?

When teams are encapsulated the problems become more obvious. Here are some examples:

  • Teams don’t understand the problem they are trying to solve and simply take on work
  • Taking features or stories with dependencies into a sprint
  • Not making a credible sprint plan by tasking out stories in a thoughtful way
  • Collaboration: i.e. Trouble adapting to doing work in public

As a coach, I draw the private moments into the light. Teams likely haven’t thought through how to deliver product and the team/person can be rightfully shy about not knowing about a subject. Getting used to collaborating in public is a great step towards taking responsibility. It may seem harsh to some, and it may not sound happy-go-lucky, but a lot of people are essentially sick and need some medicine. My empathy is like that of a doctor, in order to get the desired outcome, you will need to take this medicine and go to physical therapy… a lot.  It’s my job to prescribe, it’s theirs to do the intense work involved in the physical therapy.

By encapsulating teams and holding them accountable for not making and meeting their commitments we are enabling (demanding even) that the culture change. That requires respect for the encapsulation of the fixed team. Movement of team members during a release, allowing side projects, percentages of people, playing utilization games, forcing work through the system are all undermining the encapsulation and ultimately the predictability and commitment of teams. If you can’t form teams, get help.

Changing Value Systems for interdependent teams

In order to promote even more predictability, the new shiny team needs a dependency free, clear backlog. That’s where the traditional Product Owner or more likely for me, the Program Team comes into play.

To accomplish this and achieve accountability, I use working agreements and definitions of done and ready for delivery teams. Via workshops, teams define working agreements, ready, and done at the beginning of forming a team and continue to refine them at each review or retrospective during the first few months. This hardens the accountability and responsibility of the team to each other and allows me to promote a servant-leader attitude for the team.

Working agreements and definitions of done and ready are powerful tools for accountability. They give the team a known state that they can be held accountable to…. If they don’t make and meet commitments, then we need to review the definitions of done and ready and figure out how they can further solidify them to become predictable as a team. This does not mean beat the team with a stick, but rather being respectful of the capability of the team to deliver. I respect that and expect it too. Say what you are going to do. Momentary lapses of meeting a commitment aside, no team should devalue the importance of their commitment. As a result, organizations can grow frustrated with the lack of predictability in the organizational roadmap. It’s important stuff and there should be a dual respect of the organization and the people.

Next time

I’ll take it up a notch. We’ll discuss program teams and scaling this structure up. I’ll give some tangible examples of accountability of program teams and even list out exactly what one program team said that solidifies the notion of letting culture emerge.  A sneak peak… “It’s ok to accept change, in this system change can be embraced” – My new favorite BA when asked what she would tell other BA’s about moving to agile.

The post Time To Up The Accountability Of Your Agile Teams appeared first on LeadingAgile.

Categories: Blogs

Inkremente und Iterationen in der Hardwareentwicklung

Scrum 4 You - Wed, 12/03/2014 - 08:30

Mike Cohn hat kürzlich den Unterschied zwischen inkrementeller und iterativer Entwicklung deutlich gemacht und dabei eine Dating-Webseite als Beispiel genommen (hier geht es zu seinem Beitrag). Wie aber sieht es in der Entwicklung von Hardware-Produkten aus, die aus Software, Mechanik und Elektronik bestehen?

  1. Wer das Produkt inkrementell baut, der fügt Teile nach und nach zusammen: Gehäuse, Anschlüsse, Signalanzeigen, Sensoren, Bedienoberfläche.
  2. Wer das Produkt iterativ baut, der verfeinert es mit jedem Schritt: Vom gebastelten Prototypen bis zur Nullserie, die unter Produktionsbedigungen gefertigt wird.

Wer alleine dem ersten Weg folgt, mag zum Schluss ein robustes Gehäuse, geschickt positionierte Anschlüsse, gut lesbare Signalanzeigen, usw. in der Hand halten. Die Summe gelungener Einzelteile ergibt aber noch kein gelungenes Produkt. Das eine muss mit dem anderen so harmonieren, dass der Nutzer eine Gestalt dahinter erkennen kann. Der neue Samsung Gear Fit ist ein gutes negatives Beispiel. Im Review werden ihm ein fantastisches Aussehen, tolle und weitreichende Funktionalitäten, und insgesamt ein gutes Design attestiert. Trotzdem scheitert das Produkt, weil es weder als Smartwatch noch als Fitness-Tracker daher kommt, sondern dazwischen fällt (hier der Link zum Review durch CNET).

Wer dagegen dem zweiten Weg folgt, kann wenig falsch machen. Er wird nämlich von Anfang an das Gesamprodukt in der Hand halten. Natürlich: In den ersten Iterationen wird das Produkt sehr rudimentär aussehen und kaum Funktionalitäten beinhalten. Aber alle kritischen Fragen entspringen aus dieser ersten Gestalt: Größe und Form des Gehäuses, Positionierung der Anschlüsse und Anzeigen, Art und Nutzung der Sensoren, Aufbau und Struktur der Bedienoberfläche. Diese Fragen lassen sich gar nicht anders beantworten als durch entsprechende Inkremente oder Produktlieferungen (für mich sind beide Begriffe synonym).

Mike Cohn ist in seinem Beitrag etwas blass, wenn er schreibt, dass Inkremente und Iterationen irgendwie zusammengehören. Für mich ist die Stoßrichtung entscheidend. Ein inkrementeller Ansatz läuft Gefahr, gesichtslose Produkte zu liefern, die aus lokal optimierten, aber dissonanten Teilen bestehen. Ein iterativer Ansatz bannt diese Gefahr von Beginn an, indem er das Produkt in seiner Gesamtheit und all seiner Imperfektion zur Schau stellt. Es sind dann genau diese Imperfektionen, welche die Inkremente motivieren und letztendlich validieren.

Categories: Blogs

Finally - Disruptive Innovation in Construction

Agile Complexification Inverter - Wed, 12/03/2014 - 06:33
Otis did a wonderful thing back in the 1850s and sparked the verticalization of cities.  Ever wonder why Paris is such a wonderful feeling city?  It's because most of it was built before there were elevators.  So the practical building was limited to about 5 floors.  And the top floors were the cheeper rent, because you had to huff your groceries up all those stairs.

So here's what lack of true innovation does to an industry... it sets it's sights on just the one single solutions.  That is to make vertical buildings with duplicate floor plans, story after story for 100 or so floors.  And that results in the architectural wonder known as the sky scraper.  Good for little else but setting height records (and then fighting over what to measure at said height - a living floor or a radio antenna).

Wait a few decades (or 8 score in this case) and someone comes up with a disruptive innovation.

Is this it?  The disruptive innovation in buildings that allows architects to think in other dimensions?

MULTI - an elevator that has no rope, and moves horizontal also.

ThyssenKrupp hails its technology called MULTI "as the greatest innovation in the field since Elisha Otis and his demonstration of emergency breaks in 1854."
By-the-way, we do this type of disruptive innovation in the software fields every few years - yet people still compare developing software projects to constructing a sky-scraper.  A joke to prove the point:
For Christmas, the JavaScript community will be bringing out a new framework that you should re-write all your projects in.

Categories: Blogs

New Pivotal Tracker UI and API V5 Now Out of Beta!

Pivotal Tracker Blog - Tue, 12/02/2014 - 23:24

There’s a fresh, newly redesigned Pivotal Tracker, with a ton of new features, optimized for growing teams. But you probably already know that, because most of you have been using it for months now! Thanks for all the great feedback, Tracker wouldn’t be what it is today without such a passionate and involved user community. 5_project_page_2 If you haven’t tried it yet, you’re missing out on a faster, more flexible UI, with in-app notifications, side-by-side project visibility and collaboration, cross-project search, and so much more. And it’s just a start, we have many big things planned for 2015. The new UI is now the default for all new users, and will become the default for everyone later this week, on Thursday, Dec 4, 2014. If you’re still using the old UI, and need just a bit more time, you can switch back via the Web Client Version setting on your Profile page. You can keep using it until January 31, 2015, after which date the old UI will no longer be available.

New Developer API (V5)

The vastly improved, comprehensive developer API V5 is also now out of beta. It’s been super stable for most of the year, and many great Tracker tools and integrations have already been built with it (check them out in the App Bazaar). Note: Now that it’s out of beta, it means that we will not be making any potentially “breaking” changes to the API endpoints or the representation of JSON data being passed in/out. We may add new parameters and/or resource properties at any time though, so please keep that in mind when writing code against the API. Full documentation for the developer API can be found here.

Keeping up with Updates

2015 is going to be an exciting year for Tracker, so make sure you don’t miss out. Follow us on Twitter or Facebook, and as always, please send any feedback for the team to

The post New Pivotal Tracker UI and API V5 Now Out of Beta! appeared first on Pivotal Tracker.

Categories: Companies

Lipstick on a Pig – Moving into the “Future” [again!]

Mike Vizdos - Implementing Scrum - Tue, 12/02/2014 - 22:24 -- Cartoon -- December 4, 2006 - Original

“Lipstick on a Pig”

Have you heard this before or is this a new term to you?

For some history of the term used here at check out the following two posts:

2008 (wow… a while ago huh?!?)

2006 (almost EXACTLY eight years ago — holy cow… this is NOT a new term here, huh??).


Jumping back six, eight, and even many more years ago…. I am pretty sure you and I have both seen people trying to clean up some old stuff and make it “new” again.

Then…. actually make no REAL changes.

Would these comic strips be an ironic use of ME trying to put lipstick on a pig?

Perhaps.  Heh.

But.  I mean AND (really)….

If you’ve been following me here for years — or you just started hearing and reading about these cartoons — you know that I call things as I see them.

Look around at where YOU are working today.

How different is it TODAY versus last year this same date.  Or even two, four, six, eight, ten, twenty+ years ago?

Is it?


If you’ve been sitting around steeping in your own shit (or even worse… from someone else) and just calling what you do today “different” than the past and NOTHING has changed.  Um.  There might be a problem.

I’ve been there.  I can still go there if I let myself.  It’s human nature (I am learning).

Change.  It’s hard.  And.  It’s an overused word.

Instead of putting lipstick on the same pig, are you up for a change?

Sure.  Scrum can help you.  It’s not just a stand-up-reporting-thing-with-fully-utlizized-resources-allocated-to-five-projects-at-42%-each-project-so-lets-call-ourselves-a-success-and-now-try-to-scale-it-blablalblalbllalbllablablablabalbalbala….

Go back to the basics.


The basics.

Do one thing.  Get it done.

How is this NOT lipstick on a pig for me?

It’s something I continue to work on AND share with you as I travel the world.

I’ve gotten some greater clarity in my offerings (remember I run a small company) – you can see more of this clarity now at

In addition to communicating with you on the topic of Scrum I am sharing what I am learning as a fellow human being (and possibly entrepreneur [or wanna be!]) at

Heading into 2015 (wow… this means we ARE closing out 2014 very soon)…

What will YOU do to not just keep putting lipstick on the pig?

How can I help you?



Please keep reading along as we go into next year.

I am going back to the basics here.

I’ll have more information for you regarding Scrum and HOW TO keep having those tough conversations around software development (and the rest of your business or whatever it is that your organization DOES to #deliver.

Put down the lipstick.

It’s time….

Focus.  #deliver



Categories: Blogs

Small Thoughts: Lean and Agile

NetObjectives - Tue, 12/02/2014 - 19:15
Lean is a very misunderstood term. While Lean includes a collection of knowledge about flow, Lean-management, Lean-culture and Lean-tools it is not any of these. First and foremost Lean is based on systems thinking which means practitioners take a holistic view of the company they are working in. I sometimes hear people say "we do Lean inside of Scrum." What they should be saying is "we use Lean...

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

LeanStartup Entrepreneurship Is Like Playing Video Games

Agile Thinks and Things - Oana Juncu - Tue, 12/02/2014 - 18:51
Picture from is one thing that seem to be a baseline in entrepreneurship state of mind : the addiction to "call to action".  Did you see the enlighten look of every entrepreneur talking about their idea ? The enthusiasm end commitment to take the adventure farer and farer? There is something already in the  "entrepreneur attitude" that reminds me me of video games fans : the wish to explore an exciting adventure and experiment fast some rewarding activities. Unlike older approaches about building a Startup , Leanstartup works aka video game . I wonder if its tremendous success doesn't find some root reasons in this.  Here is why 
You have 5 lives : Try-Fail-Iterate Drawing by Laurent Meurisse at
Test Driven Business for LeanStartup workshopThe most valuable thing about Leanstartup "learning loop" is exactly its learning benefit. What is exciting in playing video game ? Learning to succeed toward a clear goal. Do better and better - win points ;) - and arrive farer at each iteration. The key of holding on is the capacity to iterate in order to learn. In video game you'll have a number of chances to make experiments.  Successful entrepreneurs manage to keep options open if failure is confirmed . And limit the failure . That's all what "failing fast is about : loose only one life, and ensure that tho s"sacrifice" took you further onto your path to success. I'm sure that every video game enthusiast will say that failure is not the purpose , it's a "success dry run" .

pilgrims (Bryan Lee O'Malley's Scott Pilgrim)Validating Hypothesis : Congratulations, you have unlocked the next level !If you listen to Startup entrepreneurs feed-back, they are all hooked by the metrics Customer Discovery , validating assumptions and metrics they can collect.
The collected metrics may be AAA ( Accessible , Auditable, Actionable ) or not, there is a continuous quest for the deep market truth those metrics hold. With each new metric that leads to conclusion on customer behavior, entrepreneurs are happy because a point of enhanced value information is reached .It's like a reward that gives the wish to go further . In Customer Discovery Game each assumption validated or failed is like reaching a new level : "Congratulations , you unlocked valuable piece of data that will give you 5 extra-lives to try new experiments to validate your hypothesis "
Play is life. And life is play Playing is optional , playing is based on voluntary choice. Playing is fun and engaging.
Becoming an entrepreneur is a voluntary choice based on desire of not being judged for having fun, which leads to full engagement.
Playing is rewarding because it gives a sense of advancement ( unlocks new levels) . Feed-back from customers is rewarding because it opens new paths to explore ( unlocks new exciting options).

Entrepreneurs are like video game fun players

Related posts
Test Driven Business featuring LeanStartupEntrepreneurs What IS Your Unfair Advantage Customer Development Is Like Customer Coaching

Categories: Blogs

Testing Feature Branches Remotely with Grunt

Xebia Blog - Tue, 12/02/2014 - 18:48

At my current job we are working on multiple features simultaneously, using git feature branches. We have a Jenkins build server which we use for integration testing of the master branch, which runs about 20 jobs simultaneously for Protractor and Fitnesse tests. An individual job typically takes around 10 minutes to complete.

Our policy is to keep the master branch production ready at all times. Therefore we have a review process in place that should assure that feature branches are only pushed to master when they can't break the application.
This all works very well as long as the feature which you are working on requires only one or two integration test suites to test its functionality. But every once in a while you're working on something that could have effects all over the application, and you would like to run a larger number of integration test suites. And of course before you merge your feature branch to master.
Running all the integration suites on your local machine would take too way much time. And Jenkins is configured to run all its suites against the master branch. So what to do?

The Solution

In this article I'm going to show a solution that we developed for this problem, which lets us start multiple remote Jenkins jobs on the branch that we are working on. This way we can continue working on our local machine while Jenkins is running integration tests on the build server.
Most of our integration suites run against our frontend modules, and for those modules we use grunt as our build tool.
Therefore the most practical step was extend grunt with a task for starting the integration tests on Jenkins: we'd like to type 'grunt jenkins' and then grunt should figure out which branch we have checked out, send that information to Jenkins, and start all the integration suites.
To accomplish that we need to take the following steps:

  • Have some Jenkins integration tests suites which can take a git branch as a parameter
  • Create a custom grunt task called 'jenkins'
  • Let the grunt jenkins task figure out which branch we have checked out
  • Let the grunt jenkins task start a bunch of remote jenkins jobs with the branch as a parameter
The Parameterized Jenkins job

Jenkins offers the feature to configure your build with a parameter. Here is how we do it:
In the configuration of a Jenkins job there's a little checkbox saying 'the build is parameterized'. Upon checking it, you can enter a parameter name, which will be available in your Jenkins build script.
We'll add a parameter called BRANCH, like in the screenshot below:

Jenkins job Parameter

Then in our Jenkins build script, we can check if the parameter is set, and if this is the case, check out the branch. It will look something like this:

git fetch
if [[ -n "$BRANCH" ]]; then
  git checkout -f $BRANCH
  git pull
  git checkout -f ${PROMOTED_GIT_COMMIT-"origin/master"}

What's nice about our parameterized build job is that we can invoke it via a Rest call and include our parameter as a query parameter. I'll show that later on.

Our custom 'jenkins' Grunt task

In our grunt.js configuration file, we can load custom tasks. The following snippet loads all files in the conf/grunt/tasks folder.


In our tasks folder we create a jenkins.js file, containing our custom jenkins task.
The next thing to do is to retrieve the name of the branch which we have checked out on our machine. There's a grunt plugin called 'gitinfo' which will help us with that.
When the gitinfo plugin is invoked it will add a section to the grunt configuration which contains, amongst others, the name of our current local branch:

module.exports = function (grunt) {
  grunt.registerTask('jenkins', ['gitinfo', 'build-branch']);
  grunt.registerTask('build-branch', function () {
    var git = grunt.config().gitinfo;
    grunt.log.ok('Building branch: ' +;

And now we can start our parameterized job with the correct value for the branch parameter, like this:

    var request = require('request');

    var jenkinsUser = 'your username';
    var jenkinsPassword = 'your password';
    var jenkinsHost = 'your jenkins host';
    var job = 'my-parameterized-integration-suite'; 

    var url = 'http://' + jenkinsUser + ':' + jenkinsHost + '@' + jenkinsHost + ':8080/job/' + job + '/buildWithParameters?BRANCH=' + + '&delay=0sec';

        url: url,
        method: 'POST'

First we acquire a reference to the 'request' package. This is a simple Node package that lets you perform http requests.
We then build the Rest url; to connect to jenkins we need to supply our Jenkins username and password.
And finally we post a request to the Rest endpoint of Jenkins, which will start our job. We supply a callback called 'jobFinished'.

Putting it all together: starting multiple jobs

With these steps in place, we have a new grunt task which we can invoke with 'grunt jenkins' from the commandline, and which will start a Jenkins job on the feature branch that we have checked out locally.
But this will only be useful if our grunt jenkins task is able to start not just one job, but a bunch of them.
Here is the full source code of the jenkins.js file. It has a (hardcoded) array of jobs, starts all of them and keeps track of how many of them have finished:

module.exports = function (grunt) {

  grunt.registerTask('jenkins', ['gitinfo', 'build-branch']);

  grunt.registerTask('build-branch', function () {
    var request = require('request');

    var jenkinsUser = 'your username';
    var jenkinsPassword = 'your password';
    var jenkinsHost = 'your jenkins host';
    var jobs = [
    var git = grunt.config().gitinfo;
    var done = this.async();
    var jobCounter = 0;

    grunt.log.ok('Building branch: ' +;

    function jobFinished (job) {
      return function (error, response, body) {
        grunt.log.ok('[' + jobCounter + '/' + jobs.length + '] Started: ' + job);

        if (error) {
          grunt.log.error('Error: ' + error + (response ? ', status: ' + response.statusCode : ''));
        } else if (response.statusCode === 301) {
          grunt.log.writeln('See: ' + response.headers.location);

        if (body) {

        if (jobCounter === jobs.length) {

    jobs.forEach(function (job, i) {
      var url = 'http://' + jenkinsUser + ':' + jenkinsHost + '@' + jenkinsHost + ':8080/job/' + job + '/buildWithParameters?BRANCH=' + + '&delay=0sec';
      grunt.log.ok('[' + (i + 1) + '/' + jobs.length + '] Starting: ' + job);

        url: url,
        method: 'POST'



And here's the console output:

$ grunt jenkins
Running "gitinfo" task

Running "build-branch" task

>> Building branch: my-feature-branch

>> [1/5] Starting: my-parameterized-integration-suite-1
>> [2/5] Starting: my-parameterized-integration-suite-2
>> [3/5] Starting: my-parameterized-integration-suite-3
>> [4/5] Starting: my-parameterized-integration-suite-4
>> [5/5] Starting: my-parameterized-integration-suite-5
>> [1/5] Started: my-parameterized-integration-suite-1
>> [2/5] Started: my-parameterized-integration-suite-2
>> [3/5] Started: my-parameterized-integration-suite-3
>> [4/5] Started: my-parameterized-integration-suite-4
>> [5/5] Started: my-parameterized-integration-suite-5

Done, without errors.

Categories: Companies

If You Want to Thrive at Microsoft

J.D. Meier's Blog - Tue, 12/02/2014 - 17:01

I was reading back through Satya Nadella’s email on Bold Ambition and Our Core, and a few things caught my eye.

One of them was the idea that if you want to thrive at Microsoft, you need to drive change.

Satya writes:

“And if you want to thrive at Microsoft and make a world impact, you and your team must add numerous more changes to this list that you will be enthusiastic about driving.

Nothing is off the table in how we think about shifting our culture to deliver on this core strategy. Organizations will change. Mergers and acquisitions will occur. Job responsibilities will evolve. New partnerships will be formed. Tired traditions will be questioned. Our priorities will be adjusted. New skills will be built. New ideas will be heard. New hires will be made. Processes will be simplified. And if you want to thrive at Microsoft and make a world impact, you and your team must add numerous more changes to this list that you will be enthusiastic about driving.”

Change is in the air, and Satya has given everyone a license to thrive by re-imagining how to change the world, or at least their part of it.

For me, I’m focused on how to accelerate business transformation with Cloud, Mobile, Social, Big Data and the Internet of Things.

Together, these technology trends are enabling new end-to-end customer experiences, workforce transformation, and operations transformation.

It’s all about unleashing what individuals and businesses are capable of.

Categories: Blogs

Getting The Most Out of Your Agile Testing

Agile Management Blog - VersionOne - Tue, 12/02/2014 - 16:44

Guest post by Kevin Dunne, product specialist for QASymphony

Getting the Most Out of Your Agile Testing

Testing—even in agile environments—is almost always constrained. Testers and developers may feel beholden to legacy software investments or stuck with status quo methodologies. Or, they’re just too busy testing to re-evaluate their processes and tools. Continuous attention to technical excellence and good design must encompass the testing function. And when it does, you can expect a higher-quality product and faster timeframes.

Blurring the Lines

Picture a manufacturing plant with cells of specialized workers segmented by skills and job output. When one group of workers in a cell completes a segment of work, the product moves to the next group of workers in an iterative process. In many development teams, developing and testing cycles occur in a similar fashion. Developers write code, and once it’s complete, the testers test. Agile replaces this outmoded factory model with integrated development cycles and collaboration. This means testers and developers are side by side, creating a lot of beneficial scenarios, including:

  • Early clarification of software expectations,
  • Shortened feedback loops, and
  • Streamlined communication

When testers are involved in the sprint, it helps ensure that test design is integrated very early in the process. The testers provide their input and expertise as to what can be completed realistically and delivered across sprints. And they are usually in tune with the customer, able to distinguish between design and intended use of an application from the way an end user will actually interact with it.

Integrating the testing function early on helps product owners clarify acceptance criteria and identify risks. Consider giving testers direct access to the customer to expose them to the customer’s desires for functionality. Then testers can immediately begin to translate customer needs into testable user stories. The “tester” mentality can help the team discern between reasonable and unreasonable expectations, and may give some indication of how delivery of expectations will be measured.

Test Early and Test Often

Many teams start the development process by prototyping and wire-framing to create a visual representation of content. When you enter all your requirements into an agile testing platform once your wireframes are complete, it is possible to show the developers what you’re trying to create—and show the tester what they need to validate—almost simultaneously. The testers utilize requirements for traceability, creating a test plan for each one. Developers and testers work on requirements and functional test plans in tandem, instead of tacking testing on at the end. Plus, integrated testing helps identify bugs early so developers can fix them fast. Instead of waiting until the code is developed to figure out if the acceptance criteria is met, and scrambling to fix the bugs before the product has to ship, development and testing occur concurrently on agile teams. When you can perform quality assurance in line with development, you will achieve high quality and high velocity.

Always Be Testing

A major initiative for most development teams is to reduce overall testing cycle time. Embedded testers can help teams shorten feedback loops—as less time passes between when a developer writes the code, the code is executed, and information is provided about how the code behaves.

Testers ensure that regression testing is built into the development process. Then as soon as code is loaded into the build, it can be tested. The longer it takes to identify code that doesn’t function properly, the more work product must be unraveled to find the source of the bug. Finding and fixing bugs early helped eliminate duplication and wasted man hours.

If you have access to a central dashboard, try to make real-time results and stats available to everyone on the team to “see as they go.” At any time, developers, testers and clients have visibility into what is happening throughout the process, fostering an inclusive problem-solving culture.

A Better Agile Testing Approach

Good design and technical excellence also apply to testing. Applying agile principles to testing, and incorporating testing into the agile environment means:

  • Development times are shorter
  • There is less process/documentation and more collaboration/interaction
  • All development team members, not just testers, are responsible for quality

If your testing approach and technology are not allowing you to provide intelligent, analytical, real-time feedback to development, are you truly getting the benefits of agile you could be?

About Kevin

Kevin Dunne is a product specialist for QASymphony, striving to ensure the continued success of existing and prospective members of the qTest community. Having acted as a tester in his previous jobs, Kevin enjoys interacting with customers on a daily basis to keep current on the latest trends and tools in the testing world. He is always eager to hear what others think about the industry – feel free to drop him a line at

Read more on agile test management


Categories: Companies

Who Removes Your Obstacles?

Johanna Rothman - Tue, 12/02/2014 - 16:21

In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice.

In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice.

And, what if you aren’t doing Scrum, or you’re transitioning to agile and you don’t yet have a self-organizing team? Maybe you have an agile project manager. Maybe you have a team facilitator. Not every team needs a titled manager-type, you know. (Even I don’t think that, and I come from project management.)

Maybe the team bumps up against an obstacle they can’t remove, even if they try. Why? Because the obstacles the team can’t remove tend to fall in these categories:

  • Cross-functional problems across several teams or across the organization
  • Problems up the hierarchy in the organization
  • Problems that occur both places, as in over there in another department and higher up in the hierarchy

Oh boy. Someone who either used to be technical or used to be a first-line manager is supposed to talk to a VP of Support or Sales or the CIO or the CTO or “the Founder of the Company” and ask for help removing an impediment. Unless the entire organization is already agile, can you see that this is a problem or a potential problem?

Chances are good that during an organization’s transition to agile, the team’s facilitator (regardless of the title) will need help from a more senior manager to remove obstacles. Not for the team. For the rest of the organization.

Now, I would love it if the person who is supposed to remove obstacles was that designated facilitator (Scrum Master, agile project manager, whomever). And, that designated facilitator had the personal power to do it all by him or herself. But, I’m a realist. In my clients, that doesn’t happen without management support.

Is it a problem if a manager removes obstacles?

I don’t think so, as long as the manager supports the team, and doesn’t prevent the team from solving its own problems.

Here are examples I would expect the team to solve on its own:

  • Not finishing stories inside an iteration because there is too much work in progress or each person take his or her own story. This is a problem the team can manage by reviewing the board, or by pairing or swarming. The team has many options for solving this problem.
  • Too much work in progress. Again, the team can often manage this problem. The first step is to see it.
  • Not getting to “done” on stories. The first steps are to make the stories smaller, to make sure you have acceptance criteria, to work with the product owner on making stories smaller, those kinds of things. Maybe the first step is to make sure you have integrated testers into your team. But that might require managers to help.
  • Having trouble deciding what team norms are and the resulting issues from that.

Here are obstacles mid-level managers or more senior managers might help with:

  • Creating cross-functional teams, not silo’d teams. I keep seeing “developer” teams and “tester” teams being told “Go Agile!” No, agile is a cross-functional team where you have all the roles you need on one team to accomplish the work. This misconception is often a management misconception.
  • Which project is #1 (managing the project portfolio). If the team has a ton of interruptions or a demand for multitasking because management can’t decide which project is #1, I would expect some manager to take this obstacle on and resolve it. The pressures for multitasking or interruptions often arise from outside the team.
  • How the organization rewards people. At some point, agile bumps up against the culture of individual rewards. Managers might be the ones who need to manage HR.
  • When the product owner goes missing, or the team has no product owner. The team is now missing a key piece to their success and what makes agile work. Very few teams can demand a product owner, especially if they are new to agile.

This is a form of management as servant leadership, where the manager serves the team.

Do you see how certain problems are inside-the-team problems and the team can solve them? Other problems are not inside-the-team problems, and are part of the organization’s system. The organization needs to decide, “How committed to agile are we?” and address these issues.

Categories: Blogs

Why Being Agile Matters

Rally Agile Blog - Tue, 12/02/2014 - 15:00

If you're reading this blog chances are you're more than a little familiar with Agile. Maybe you've been experimenting with Scrum on a project team, or maybe you're doing SAFe™ release trains in your sleep. Maybe you don't even call it Agile anymore -- it's just "the way things get done."

Maybe it would surprise you, then, to learn that in many, many offices around the world, there are no standups, no user stories, no sprints, and no retrospectives. While the number of organizations employing Agile is growing -- Computer Economics estimates that 83% of businesses have future plans to implement Agile, an increase from 59% last year -- Forrester estimates that more than 50% of all projects are still done using traditional or "waterfall" methods. Agile isn't a common buzzword, much less a commonly used approach, in organizations big and small. Just think of all those under-achieving sticky notes.

photo: Flickr, Creative Commons

What this means is that there are still a lot of people who don't know important facts you may take for granted. What is this Agile thing, anyway? How is it different from traditional project management? What are the benefits of adopting Agile approaches? What are some of the obstacles to making the switch?

At last month's Agile Singapore conference, Rally’s regional vice president for Asia, Bryan Tan, had an opportunity to address some of these questions for a market that is just beginning its journey with Agile adoption.

Why Companies Should Go Agile

“The rapid advances in technology and growing consumer demands have put more pressure on companies to deliver products and services at a much quicker pace than before," said Bryan. "The technology disruption curve is a lot steeper and shorter now, so companies need to be Agile to stay competitive.”

How Agile Development Works

“[In traditional project management] you usually gather requirements from users before the technology development team takes over. It could take six months to two years to come up with a working prototype. Then, the product goes through a user acceptance test, but by that time business conditions may have changed.

“In Agile development, tasks are defined in smaller components called stories, which should meet requirements. These stories would be ‘carried out’ by cross-functional teams that would look into different parts of the implementation process. Teams could be made up of designers, testers and coders. There’s also a product owner who ‘owns’ the product or business needs.

“There are different ways to implement agile development. One of them is Scrum, an iterative agile software development framework. Some companies choose the Kanban method, which is more process-oriented. Whichever method they choose, teams usually take two to four weeks to deliver an iteration of a working product. Then, they refine the product and come up with the next iteration.”

If Agile’s So Great, Why Isn’t Everyone Doing It?

“Large-scale agile projects are a big challenge, especially in Asia where companies are later than those in the US in adopting agile development … I think it’s the fear of failure that’s holding back adoption of agile development in the region. Most organisations are taking a wait-and-see approach.

“[T]he most important thing is that a company’s leadership has to support the transformation into an Agile organisation. That drives the culture so people will pay attention. From the bottom-up, you need to train your people to become Agile.”

How Rally Speeds Agile Adoption

“Some organisations that practise agile development have very large distributed teams, making it hard to track the progress of stories. That’s where you need technology. We provide a platform that teams can use to define and capture stories, as well as track how they’re performing against other teams.

“We train our customers to be independent and self-sufficient. The sooner companies have internal coaches to lead their agile development efforts, the faster they’ll see success. For those who are afraid of disrupting their businesses, start with one or two pilot projects. We have helped companies do that, by assessing their pain points, followed by identifying a business unit to do the pilot. Then, we look at their process and train people in what we call a programme launch, which takes two to three months. Once people are trained in Agile development, we’ll do a team launch where we’ll look at translating stories into products. If the pilot project is successful, we can implement it for other business units.”

Read Bryan Tan's entire Q + A interview with Singapore-based TechGoondu, here.

Rally Software
Categories: Companies

How Agile Leads to Functional Design and TDD

Scrum Expert - Mon, 12/01/2014 - 20:52
In this blog post, Ralf Westphal explains how functional design and test-driven development (TDD) are the techniques that allows to bridge the gap between requirement and code in Agile. He defines a three phase process: 1. Analyzing the requirements but not only to understand what the customer wants, but also to slice the user’s needs into finer increments. 2. Using functional design that emphasizes the technical side of data flows, their building blocks, which are functions. 3. Coding the list of functions that have to be implemented. Its conclusion is that “Considering all the details ...
Categories: Communities

A Bit of Agile in Waterfall Project Approach

TV Agile - Mon, 12/01/2014 - 19:19
Short stories and lessons learned from a waterfall oriented organization that wants to get more flexible but language barriers and time zone difference bring extra challenges for timely delivery – from iterations to multi-year product road-maps, from individual responsibility to multi-project teams. Video producer:
Categories: Blogs

About snowmen and mathematical proof why agile works

Xebia Blog - Mon, 12/01/2014 - 17:05

Last week I had an interesting course by Roger Sessions on Snowman Architecture. The perishable nature of Snowmen under any serious form of pressure fortunately does not apply to his architecture principles, but being an agile fundamentalist I noticed some interesting patterns in the math underlying the Snowmen Architecture that are well rooted in agile practices. Understanding these principles may give facts to feed your gut feeling about these philosophies and give mathematical proof as to why Agile works.


“What has philosophy got to do with measuring anything? It's the mathematicians you have to trust, and they measure the skies like we measure a field. “ - Galileo Galilei, Concerning the New Star (1606).

In his book “Facts and Fallacies of Software Engineering” Robert Glass implied that when the functionality of a system increases by 25% the complexity of it effectively doubles. So in formula form:


This hypothesis is supported by empirical evidence, and also explains why planning poker that focuses on the complexity of the implementation rather than functionality delivered is a more accurate estimator of what a team can deliver in sprint.

Basically the smaller you can make the functionality the better, and that is better to the power 3 for you! Once you start making functionality smaller, you will find that your awesome small functionality needs to talk to other functionalities in order to be useful for an end user. These dependencies are penalized by Roger’s model.

“An outside dependency contributes as much complexity as any other function, but does so independently of the functions.”

In other words, splitting a functionality of say 4 points (74 complexity points) in two equal separate functions reduces the overall complexity to 17 complexity points. This benefit however vanishes when each module has more than 3 connections.

An interesting observation that one can derive from this is a mathematical model that helps you to find which functions “belong” together. It stands to reason that when those functions suffer from technical interfacing, they will equally suffer from human interfaces. But how do we find which functions “belong” together, and does it matter if we get it approximately right? 

Endless possibilities

“Almost right doesn’t count” – Dr. Taylor; on landing a spacecraft after a 300 million miles journey 50 meter from a spot with adequate sunlight for the solar panels. 

Partitioning math is incredibly complex, and the main problem with the separation of functions and interfaces is that it has massive implications if you get it “just about right”. This is neatly covered by “the Bell number” (

These numbers grow quite quickly e.g. a set of 2 functions can be split 2 ways, but a set of 3 already has 5 options, at 6 it is 203 and if your application covers a mere 16 business functions, we already have more than 10 billion ways to create sets, and only a handful will give that desired low complexity number.

So how can math help us to find the optimal set division? the one with the lowest complexity factor?

Equivalence Relations

In order to find business functions that belong together or at lease have so much in common that the number of interfaces will outweigh the functional complexity, we can resort to the set equivalence relation ( It is both the strong and the weak point in the Snowmen architecture. It provides a genius algorithm for separating a set in the most optimal subsets (and doing so in O(n + k log k) time). The equivalence relation that Session proposes is as follows:

            Two business functions {a, b} have synergy if, and only if, from a business perspective {a} is not useful without {b} and visa versa.

The weak point is the subjective measurement in the equation. When played at a too high level it will all be required, and on a too low level not return any valuable business results.

In my last project we split a large eCommerce platform in the customer facing part and the order handling part. This worked so well that the teams started complaining that the separation had lowered their knowledge of each other’s codebase, since very little functionality required coding on both subsystems.

We effectively had reduced complexity considerable, but could have taken it one step further. The order handling system was talking to a lot of other systems in order to get the order fulfilled. From a business perspective we could have separated further, reducing complexity even further. In fact, armed with Glass’s Law, we’ll refactor the application to make it even better than it is today.

Why bother?

Well, polynomial growing problems can’t be solved with linear solutions.

Polynomial problems vs linear solutions plotted against time

Polynomial problems vs linear solutions plotted against time

As long as the complexity is below the solution curve, things will be going fine. Then there is a point in time where the complexity surpasses our ability to solve it. Sure we can add a team, or a new technology, but unless we change nature of our problem, we are only postponing the inevitable.

This is the root cause why your user stories should not exceed the sprint boundaries. Scrum forces you to chop the functionality into smaller pieces that move the team in a phase where linear development power supersedes the complexity of the problem. In practice, in almost every case where we saw a team breaking this rule, they would end up at the “uh-oh moment” at some point in the future, at that stage where there are no neat solutions any more.

So believe in the math and divide your complexity curve in smaller chunks, where your solution capacity exceeds the problems complexity. (As a bonus you get a happy and thriving team.)

Categories: Companies

Product Backlog Refinement

Learn more about our Scrum and Agile training sessions on

The ultimate purpose of Product Backlog refinement is to ensure an ongoing conversation that increases transparency of the Product Backlog and therefore the Product itself – to orient everyone on the team to breaking out of their waterfall silos and focus on delivering business value, period.

On mature teams, a lot of the refinement work happens as ad hoc conversations while they are sitting around and thinking together about how to build something great because they are just motivated by that and it becomes part of their mode of operation.

The objective of the refinement work of any given Sprint (that often needs to be repeated over and over like a mantra with new, immature teams) is to ensure that the items at the top of the Backlog are transparent enough that the Development Team considers them ready to pull and get “Done” in the next Sprint.  This is where the concept of the Definition of “Ready” (DoR) comes from – the Scrum Team defines the DoR and spends up to 10% of its capacity refining enough items at the top of the Backlog so that it can provide estimates (if required) and have a reasonable degree of confidence that it can deliver the items in the next Sprint.

Refinement is NOT solutioning – I think this is the big trap that a lot of teams fall into because there is a false assumption that technical solutions need to be hashed out before estimates can be made (part of the carried-over lack of trust and communication between the business and IT) – I would almost rather throw out estimates in cases where this is not improving – The Planning Game exercise, when facilitated well, lends itself more to increasing transparency rather than solutioning.

The fact that teams are telling us that they need to solution before they can estimate is also an indication of weak Agile Engineering practices such as refactoring, test-driven development and continuous integration (XP).  The best refinement sessions are those in which the team is able to focus on the “what” – the business benefit results that the Product Owner really wants – rather than the “how” (solution).  Strong teams emerge in an environment in which they are trusted by the business and management to find the right solution as a team.  They don’t need to have it all figured out before giving an estimate because they are not afraid to give a bad estimate and fail.  Also, if the team is struggling to give estimates, this is often a sign that the Product Backlog Items are too big.  Most likely the team also needs to expand the Definition of “Done” to include testing against acceptance criteria within the Sprint so that they can estimate based on that criteria.

The “how” (solution) should be mapped out by the Development Team at a high level in the 2nd part of Sprint Planning (partly why the time box is bigger than they often think they need) and more detailed architecture, requirements and design work as part of the Sprint Backlog

But this level of maturity is very hard to do and it will take a while to get there, perhaps even years.

It also depends on your interpretation of “detail”, the word used in the Scrum Guide to describe what the team does in Product Backlog refinement. To me, it means understanding in more detail what the Product Owner really wants and needs. What does it mean to you?

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.