Skip to content


Really Bad is MUCH Better than Nothing and Really Great Isn’t Much Better than Bad

Applied Frameworks - Thu, 03/13/2014 - 18:01

Blog Editor's Note: Luke Hohmann published many great posts for We plan to re-publish his original posts (with only minor edits) over the next several months. We may add new commentary to update the content and generate new discussion.

Originally published June 3rd 2009

Product Managers, Agile or otherwise, are asked to create a fair number of documents. Even when we've replaced our "Big" MRDs with Vision Statements, Roadmaps, and Backlogs, most of us are still expected to clearly document:

  • Who we’re serving (e.g., target markets, market segments)
  • Why they care (e.g., benefits of products often expressed in ROI)
  • Why we care (e.g., market size, total available market, total addressable market, growth and share)
  • How we’ll reach them (e.g., sales channels, partner structures)
  • Our sustainable competitive advantage
  • The competitive landscape
  • Personas
  • and… ???

0 0 1 239 1364 Enthiosys, Inc 11 3 1600 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:Calibri; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} My point is that even the most minimalistic approach to Product Management has a Product Manager creating a fairly large number of documents. Which doesn't concern me, because these are quite sensible documents to create.

What does concern me is that I'm seeing an increasing number of product managers who are avoiding creating these basic artifacts. The conversation goes something like this:

Luke: "Francesca, can you show me your personas?"
Francesca: "Oh yeah -- personas. They're really great. I like the Cooper format, but I also think the format I learned from Pragmatic Marketing is really neat".
Luke: "Yes, both formats are quite useful. I'll be OK with either. Can you show me your personas?"
Francesca: "Well, you see, that's the thing. We don't have personas. You see, we really didn't have all the time we wanted to create the persona format that we thought would be great. And since we couldn't create a really great persona we decided just to skip it."

Push the big red button labeled "STOP.”

Just because you can't create a "really great" anything does not mean you should skip it.

Yes, I know. Writing a really great persona is hard. But a really great persona is merely better than a good persona. And a good persona (which looks "bad" in comparison to a _really great_ persona) is MUCH, MUCH, MUCH better than a bad persona. Logically:

"bad" Product Management deliverable >> NO deliverable

"really great" Product Management deliverable > "good" Product Management deliverable

To help get you started, I hereby proclaim that creating "bad" deliverables is OK.


  • It is OK to have a persona without just the right picture.
  • It is OK to define your Total Addressable Market as a “reasonable guess” Low-to High estimate of your Total Available Market.
  • It is OK to have a roadmap that only projects 12 months into the future.
  • It is OK to define your initial market segment as the “customers who bought from us.”
  • It is MORE than OK to define your ROI in less than 12 lines of Excel.
  • It is OK to focus more on your customers than your competitors.

What else do you need permission to create badly? Send us a note.

Previous Reader Comments

Looks like a sure cure for paralyzing perfectionism and analysis paralysis.

Reminds me of a great Development Director I worked with early in my career who said "It's better to start doing the right thing than wait until you can do it right."

June 4, 2009 | Brian (

Categories: Companies

But It’s Just a Simple Matter of Coding – How Hard Could It Be?

BigVisible Solutions :: An Agile Company - Thu, 03/13/2014 - 17:50

Many times, I hear business people (such as Product Owners) bemoan how expensive software development is.  And the brutal truth is that for anything non-trivial, software costs a ton of money to develop.  I happened upon some numbers for a fairly simple but elegant iOS app called “Twitterrific”.  Twitterrific is a client to the Twitter network, uses a well defined interface created by Twitter, and does not require any backend development.  It runs on the iOS, which is a well defined, well documented, well supported, and stable environment for both development and use.  According to an article published on the PadGadget site, Twitterrific was developed by a single person (Craig Hockenberry) in about 1100 hours.  The article goes on to do the math at $150/hour, adds in design, testing, and so on, and comes up with a number of around $250K.  That’s just for labor.  No costs for a workplace, infrastructure, developer tools, and so on.  Once you start adding in enterprise costs for offices, management labor, etc., and start building multiple tier complex applications, It’s easy to see why business people would look at the finished work (knowing how they interact with computers, which has become easier and easier over the years) and wonder “How hard could it be?”

That burning issue perplexes many organizations.  It isn’t usually an issue with companies with disruptive products – when margins are huge, things become profitable quickly and easily.  It isn’t usually an issue with a young, well funded company – if there is a long enough runway covered in money, and you aren’t accountable for showing profits until sometime far down the road, costs are not the issue.  However, it is a huge issue in many enterprise IT settings, where capitalized expenditures are rigorously scrutinized to see what work can be done under the funding constraints that exist. So, why is software such an expensive thing to create?

Here are four reasons that I find compelling.

  1. For anything other than trivial software, the potential for failure due to complexity and development risks is huge.  Back when mainframes ruled the earth in the 60s and 70s, the average program was thousands of lines of code. Today, it is very common to see applications that are tens of millions of lines of code. And, since any line of code can potentially affect any other line of code through side effects, a program that is 10 million lines of code is one million times more complicated than a program that is 10 thousand lines of code (a so called “n squared” problem).  The care needed to create code that works at all, and the potential to have bugs emerge is astronomically high.  While we have better tools now than we had forty or fifty years ago, they aren’t a million times better.  Trust me!  I developed software on machines back then as well as now.
  2. Programming is more like an art than it is engineering.  Engineering and building large and useful things on schedule has become commonplace nowadays, and people count on it.  For example, Tommy Lennhamn (from IBM), states that “Examples of successful engineering projects, at least with respect to schedule, are all the construction projects for Olympic Games — as far as I know, all Olympic Games have started on time, on fundamentally new premises.”  The secret is that with engineering problems for things like constructing buildings, components to build from are well known, assemble together well, and don’t create too many unknown side effects when bolted together.  In that type of situation the hard part about the project is agreeing on what to build.  With software, many times the business doesn’t know what to build until they build something to see if it solves the problem.  But that operates in a doubly damning world where developers don’t have the components that assemble together without knowing for sure if their construction in one place has affected something else (and someone else) in the code base.  Not withstanding the efforts of TDD, we can never prove correctness in software to the same extent that we can with mechanical construction.
  3. Not all developers are created equal.  The barrier to enter the field is relatively low.  This attracts a lot of people to compete for relatively high paying jobs.  But, as people like Steve McConnell point out (in IEEE Software, Vol. 15, No. 2), “…differences of more than 20 to 1 in the time required by different developers to debug the same problem” exist.  Does it make more sense to hire one awesome person for $200K or 10 mediocre people for $90K each?  Remember, once you hire 10 people, communication issues will slow you down (Fred Brooks “Mythical Man Month” stuff, but I digress).  While there may be a glut of cheaper labor today relative to the salary requirements of the awesome developers (due to such factors as geographic outsourcing), the reality is most enterprise IT settings would never hire the really awesome developer at a relatively high pay grade, due to political issues. And, even if they could, they would be hard pressed to find talent willing to work in the stodgy environments that many enterprise IT settings have become.
  4. There is still a wall of disengagement between business and development that needs to be broken down.  The Agile movement of the last 13 years has done a lot to publicize the need to have “Product Owners” engage on at least a daily basis (with continuous engagement being the best), but it is still very common to see business people physically and geographically separated from development.  Worse yet is when enterprise business people complain about how much “more important” work they have to do, and how they yearn to return to the days of yesteryear, when they could ask the Project Manager for a status update, and then complain when things were behind schedule.  Lean thinking tells us that faster feedback loop cycles will create less waste, and therefore more and better product.  Given the realities of 1-3 above, and the cost associated with those items, I implore such business people to stay with the development teams and help them help you reach the enterprise’s goals.

It’s a shame that software is so exquisitely expensive to make, as the opportunities to enrich our lives by using relatively cheap hardware is everywhere.  Everything from smart thermostats (such as the “Nest”) to smart light (such as the Philips Hue) to truly personal computers (such as Samsung Galaxy Gear and Google Glass) surrounds us.  And it all takes programming computers in one way, shape, or form.  Unhappily, programming computers is anything but easy.  But if you consider that humans have been building houses, roads, and bridges for thousands of years, and are still faced with colossal failures from time to time, it sort of puts things into perspective.  Programming will continue to evolve into something more of an engineering practice someday, and programming may eventually become something relatively simple.  Of course, we’ll have to find something else to complain about if that ever occurs!

Kinky for Governor Poster

Kinky Friedman ran for governor of Texas in 2006 on the slogan is “How Hard Could It Be?” While this was a great line, no one, including Kinky himself, ever believed it. Even Kinky admitted that “I’ll hire good people!”

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


The post But It’s Just a Simple Matter of Coding – How Hard Could It Be? appeared first on BigVisible Solutions.

Categories: Companies

Architectural Bodystorming

Growing Agile - Thu, 03/13/2014 - 10:00

A few years ago I was introduced to the concept of bodystorming. Basically this is acting out in person how a product might be used as a way of coming up with product ideas and requirements. I tried it out at a coach retreat, but didn’t really have any ah-ha moments that made me want to use it with a client.

Then yesterday driving home from a client, I was thinking about ways to visualise and simplify their incredible complex architecture with over 40 different subsystems. I had an idea! What if we bodystormed the architecture?

Each person can act as a component, or group of components (depending on how many people you have and how complex your architecture is). Each person gets a stack of index cards to represent the type of messages their component(s) send.

People stand around in a way that represents the components relationships to each other. i.e. if 2 components share a database they stand close together. If something is deployed on a different server to the rest they stand further away.

One (or more) people represent the users of the system. They have a bunch of cards indicating the types of things users do.

Maybe also try have a few people just observing.

The people representing users then decide to initiate an action. They have to walk over the the component they would interact with and hand them the card to represent that action. Now people move and pass messages the way the system would. Hopefully ending up with the result being passed back to the user by someone.

Do this for a couple of requests and even try things like multiple simultaneous requests from different users.

Now reflect. What happened? What patterns did you notice? Was anyone particularly busy? Was anyone completely idle? Did stuff pass back and forwards between people who were far apart? Was there a simpler way to get the right message back? Did anyone get confused about what they were supposed to do?

What does that say about your architecture? Are there some things you could change to streamline it? simplify it? Does everyone have the same understanding of how the system  works? Did anyone say it ‘should’ do this, but actually it does that?

You could take it one step further and make some changes to the way people are arranged based on how you’d like to improve the system and then play the same scenario’s again and see if the impact you expect is achieved.

I haven’t tried this technique yet, but I suspect you could use it for a couple of things:

  • Knowledge Sharing – particularly with a large system to get a shared understanding of how it actually works.
  • Refactoring – be able to visualise the state of your system and then try out how it might work if you re-architected it without writing any code.
  • Deployment Strategy – use this to decide how best to deploy components based on frequently they interact.

I think the strength of this technique lies in making tangible something that is often very intangible – software architecture.

If you are based in Cape Town, and the idea of trying this excites you, give us a call. I’d be keen to help facilitate the session to see how the idea works in practice. I’ll do it for free just for the learning experience icon wink Architectural Bodystorming

Categories: Companies

The Role of Scrum Master – A Permanent Position?

BigVisible Solutions :: An Agile Company - Wed, 03/12/2014 - 21:27

As agile frameworks grow in both popularity and widespread use, especially with Scrum leading the way, Scrum Masters have grown in popularity with companies, and we see an increase in job postings specifically for them. However, we have to understand that “being” an SM is not a position to occupy, it’s living up to a set of responsibilities.

Although the role itself is an artifact of Scrum, the responsibilities of the role are nothing new for a healthy team environment. A Scrum Master needs to support the team’s ability to focus on what is important and deliver on commitments.
team leadership
When organizations implement agile frameworks, a Scrum Master role is needed to help teams re-learn the discipline of healthy delivery. But as time goes by, the responsibilities need to be absorbed by the entire team. There may be one person that takes a lead, but the mantle lies on the entire team’s shoulders, and the position of Scrum Master slowly phases out as a new team capability emerges: leadership.

Leadership at the team level is something we have slowly diverged from in the name of organizational efficiency over the last few decades. Management theory has taught us that the most efficient way of managing the work is to remove tasks and responsibilities outside of each person’s job description. So developers should only do development, QA only testing, etc. Leadership is seen more in terms of a craftsman expertise with a focus on tightly controlling the work itself.

I don’t know if “Scrum Master-ing” is a professional endeavor for a life-long career or more of a step along the way. I think that the more you practice it, the more you really dive into becoming a change agent. The responsibilities of the role lend themselves naturally to that progression. For instance, the more teams you lead as a Scrum Master, the more you learn to read the patterns of impediments, and the more you will seek to prevent/mitigate the formation of problems you have observed in the past. Why wait until challenges materialize when we can go out and influence the outcome early, right? And you would do that by influencing the environment in which the patterns are forming to help “change” the circumstances that are developing. Now, you’re now thinking like a change agent.

Like a good leader, a Scrum Master builds a legacy for the team to perpetuate once the position is no longer needed. And now the role persists through the team.

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


The post The Role of Scrum Master – A Permanent Position? appeared first on BigVisible Solutions.

Categories: Companies

It’s Teamwork. Rescue Me, Quotation.

TargetProcess - Edge of Chaos Blog - Wed, 03/12/2014 - 14:39

My twitter stream delivered an interesting quotation about quotations yesterday. This one, and the tweet came from Bob Marshall:

A quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business.

Quotations indeed take a fairly large part among tweets and other social web shares. When something troubles us at work, whether we are looking for a solution to a technical or to an organizational problem, and if talking it out with friends and colleagues is not enough,  or we are shy and/or unwilling to speak, we find outlet in sharing quotes by reputable gurus, and those quotes reflect how and what we think about this problem.

I only in part agree with the quote by A. Milne above. The habit of using quotations can be perceived as lazy thinking, sometimes. However, I don’t think that people who share quotes or links online are the lazy ones. On the contrary, they are the ones who do think. It’s just that for the time being they are shy to step forward with their opinion, expressed in their own words. It might be even scary for some, to stand out and say: yes, these are my thoughts, and my words and I’m ready to be accountable for them. We are all human, and we all have things that we are not yet ready to let out to the outer world. This might be out of fear, or out of passive-aggressive reactions, or … <insert your reason here>. We might be too lazy to care about building formal logical discourses so as to pass on the message to those who do not share our thinking right away. Some people seem to resonate naturally with each other, and with some people a heavily geared-up persuasive rhetoric has to be used. Take a moment and think: which people in your social circles throw links or tweet quotes instead of writing or speaking up? They are just not yet ready to make this leap, the shift from the safe protection of quotes and references to the scary uncertainty of how the world and others would react to what would then officially be treated as their own opinion. Absolutely, they need to be encouraged to speak out and to write up.

The scary uncertainty got hold of me and of my article on self-organization earlier this week. I expressed my own opinion, backed up by intuition and personal experience,  and didn’t pay much attention to references, details and credibility proofs. If I did, it would take a book, not just one article. Anyway.

There’s another controversial subject that probably has many heads in software development thinking about it. I want to bring it forth, but this time I will take a safe protection of George Lois, an advertising guru, who wrote the book called “Damn Good Advice (For People with Talent!). Software development is a creative pursuit, at least, when it comes to the ideas part, so I was delighted to see that a recognized creativity guru thinks about teamwork along the same lines that I do. The subject of groupthink, and the dynamics of software development teams working efficiently together has preoccupied me for quite some time, but I will hold back my thoughts for now, letting George Lois speak instead:

Team work might work in building an Amish barn, but it can’t create a Big Idea.

The accepted system for the creation of innovative thinking in a democratic environment is to work cooperatively in a teamlike ambience. Don’t believe it. Whatever the creative industry, when you’re confronted with the challenge of coming up with a Big Idea, always work with the most talented innovative mind available. Hopefully.. that’s you.

Avoid group grope and analysis paralysis. The greatest innovative thinker of our age remains Apple cofounder Steve Jobs, a modern-day Henry Ford. Jobs was not a consensus builder but a dictator who listened to his own intuitions, blessed with an astonishing aesthetic sense.

Everybody believes in co-creativity — not me.

Be confident of your own, edgy, solo talent.

Wait, wait. Before you throw rotten tomatoes, George Louis does give credit to teamwork, and I do, too. Here’s what goes next in the book:

Once you’ve got the Big Idea, that’s where teamwork comes in – selling the Big Idea, producing the Big Idea and bringing the Big Idea into fruition.

For props, here’s how the Amish barn construction site looks. George Lois has this image right in the book.
building an Amish barn

Related articles:

People We Like

Dissecting Dysfunctional Meetings

Uselink: Organizational Culture and Development Process

How Communication Factors In To Production

Categories: Companies

Rally at Startup Weekend 2014

Rally Agile Blog - Wed, 03/12/2014 - 13:00

Ideas are cheap. As Thomas Edison is famously supposed to have said,

“Genius is one percent inspiration, ninety-nine percent perspiration.”

This weekend, March 14-16, Rally Software will be cheering on dozens of passionate entrepreneurs as they race the clock to take an idea from conception to startup. During this 54-hour Startup Weekend, entrepreneurs will pour inspiration and perspiration into their ideas to validate them and launch startups.

At Rally, we’re passionate about encouraging innovation internally and within our community. We follow Lean Startup principles in the enterprise context, and Zach Nies, Rally’s Chief Technologist, will be guiding the Startup Weekend teams on adopting these principles. It’s a process that encourages focus on “getting out of the building” to validate ideas with potential customers, and rapid cycles of “frame, build, measure, learn” to discover what customers need., a product initially created by a team of interns at Rally last summer, is an example of how Rally runs experiments to understand the needs of developers. Engaging with Startup Weekend is one way for Rally to see how small teams are formed, how they work together, and how they adopt tools to help them solve problems.

Counter to common thinking, entrepreneurs are ideal candidates for Rally. As the company grows, we need innovators who can push Rally to discover and meet our customers’ needs: not just today, but in years to come. Investing in Boulder’s startup community helps us build relationships with the next generation of entrepreneurs and leaders.

Are you an entrepreneur? Are you passionate about taking an idea to market? Join us at Startup Weekend, March 14-16, in Boulder, CO. Use coupon code RALLY to get $20 off. 

  Andrew Homeyer
Categories: Companies

2 Approaches to Focus in Knowledge Work

TargetProcess - Edge of Chaos Blog - Wed, 03/12/2014 - 12:49

If I were to single out one personal skill that matters most in work and in life in general, that would be the ability to focus. It’s ever so hard to keep focus in the digital age, with all those many distractions that lure us; and it might be especially hard for IT-specialists, people who spend most of their time cuddling with computer screens.

Digital creatives are more inclined to having their focus loosened. Their work allegedly requires a good deal of looking at how others do things. One can easily get lost in graphics, designs, promotional concepts, and have all their buckets so filled up with what someone else has created, that they would have difficulty detaching and focusing on their own thing. I’m mostly talking about UX designers, graphic designers, marketing specialists, and other roles that involve the mixture of creative and strategic thinking. It’s both a very fine line and an insidious trap: whether we absorb all the treasures of the world, re-mix them inside of us, and produce another facet of digital reality available for all people through their screens; OR we strangle our creativity by blocking its flow with passive perceptions, disrespecting our innate abilities to bring something authentic to the table. Ultimately, that would be one and the most important thing that we need, if we ever want to be fulfilled professionally and to have people enjoy software products that we create: focus on this well of creative thinking inside of us, nurture it and let it find an outlet.


How about other IT specialists? Software developers and quality assurance who, on the contrary to the creatives, seem to be too focused on their work? It’s hard to believe, but in some companies they still block access to social sites, or even to the Internet, not to let even a single second of work time sneak anywhere outside. The employers who allow such things to happen obviously mix people with machines. There’s no way a human being will work more productively if treated as an inanimate object. On the contrary, developers and QA need to be encouraged to distract from their work time after time, to be able to keep their focus on it.

These are 2 basic approaches to keeping focus in knowledge work, and any work in IT is knowledge work, as we know (tautology intended). Creatives need to be encouraged to tap inside themselves, to learn when and how to block distractions and outside influences. Technical specialists, on the contrary, experience emotional drain if they don’t have some relaxing outlets and distractions at work. It takes some high-profile personal skills to balance the focus-loosening phases, and it seems there’s no ready-made universal recipe for that. What works for someone, might not be working for someone else. My personal indicator is this: if I feel that my time is wasted — something wrong’s with the focus; if I feel that my time is spent productively — this shows that I’m well-focused. I hope we all will have this focused feel all the more often, as our work helps us learn how to do things in a productive and personally fulfilling way.

Related articles:

Are You A Copycat?

Cognitive Endurance Basics for Software Developers

Top 5 Non-Office Brain Killers

Categories: Companies

The Essence of Agility: Becoming Safer by Controlling Less

BigVisible Solutions :: An Agile Company - Tue, 03/11/2014 - 17:09

The other day, I presented at Agile India 2014 on the topic of “Pivoting Your Organization to Become Agile Testers”. Near the end, when I was tying up all the points in the talk, I was speaking about wastes that come from “big batch thinking” and gave an analogy off the cuff (and way off my talking points!) to illustrate why the most useful testing should be automated at a product functionality level.  The analogy I conjured up is powerful, and is an application of lean thinking that has value in so many enterprise-type organizations.  The basic message is that by planning less (not attempting to not try to preplan so such about how things will work, but instead concentrate on showing that things actually are working) and lightening up on process controls, we can gain a lot in the sense of getting actual stuff done, and not just measuring the busy work that accompanies getting that stuff done.

The analogy I used has to do with cars and the flow of traffic.  It starts with the 20th century concept of separating drivers from pedestrians, which was developed to keep pedestrians safe from fast moving cars and to allow cars to be driven without constantly fearing that they might run into pedestrians.  As wider and faster roads developed, the need to use road signage and traffic signals to control the flow of movement became both an expectation and a necessity.  But the traffic signs and signals had an unintended consequence.  Drivers felt that if they simply obeyed what the signs told them that they were allowed to do, they could be safe in just driving and not have to worry about the current conditions or how they needed to react to them.  Some people slowly began to question these assumptions.  For example, Hans Monderman, the Dutch road traffic engineer behind the Drachten Experiment (more about that in a minute), has said, “A wide road with a lot of signs is telling a story.  It’s saying, go ahead, don’t worry, go as fast as you want, there’s no need to pay attention to your surroundings. And that’s a very dangerous message.”

An interesting way of “seeing” the issue of inattention when concentrating on a task at hand is to experience “The Monkey Business Illusion”.  Take a minute to try the YouTube video and play along!


Are you back?  How did you do?  Think of how this applies to driving, and maybe even some close calls you had when driving.  When our attention is on task to do something specific asked of us, such as “Count how many times the players wearing white pass the ball”, or “Speed Limit 50 MPH”, we can easily lose the bigger perspective of very important things.

Anyhow, back to “The Drachten Experiment”.  Drachten, a Dutch town in the Netherlands, is an old medieval city that has been growing steadily in the past 60 years.  The town had a problem that it wanted to solve.  It wanted to lessen downtown traffic congestion and reduce traffic accident rates at the same time.  For 100 years, the accepted way to accomplish this has been to separate people and vehicles, introduce road signs and traffic signals, and have strict rules on who has the right of way and when.  But the town had enough of that school of thought, and felt it could go better by doing something which seemed weird at first glance.

What Monderman did for Drachten was to remove all of the traffic lights and road signs from the town’s center.  This had the effect of reducing accidents from about 8 per year before the experiment to about 1 per year after the experiment.  Throughput, even in the face of additional traffic numbers, has increased with average measured delays reduced from about 50 seconds to between 10 and 30 seconds.  An explanation of the reduction in accident rates is that many drivers habitually race through traffic lights right before they turn red.  They get lulled into a false sense of security by the confidence that they have right of way – making them less aware of potential hazards, such as people that are anticipating the changing traffic signal and ready to assert their right of way.  Perhaps you can recall an experience like that.  It usually evokes pangs of anxiety as we think about what could have happened.

Drachten before Hans Monderman.


Drachten after Hans Monderman.

The trouble is that we have the same sorts of issues when we do traditional project management.  We preplan the dependencies, map out what the expectations for what final integration will be, and then start reporting on how close each sub-project is towards the ultimate goal.  We install our own forms of traffic signals, called “gates” in traditional project management, and have fairly high ceremony events, using terms like “go / no go” decision points.  In our zeal to track and manage progress towards the ultimate goal, we can be blinded to the actual problems facing the project.  The false security that we get from showing progress against the plan, by using the process we employ, can blind us to the fact that a gorilla has come on the stage, that the curtain has changed color, or that our car now poses a treat to a pedestrian entering the cross walk.  Successful projects don’t get that way by just being right on the process.  They have to pay attention to the right things that change, and make sure that the relevant issues are surfaced as quickly as possible to avoid last minute close class (or worse!)  Letting go of some process gives much better results than rigid control of flow.  That’s what agile planning is all about.

Lao-tsu, in the Tao Te Ching, said it best:

Stop trying to control. Let go of fixed plans and concepts, and the world will govern itself.  The more prohibitions you have, the less virtuous people will be.
If you don’t trust the people, you make them untrustworthy.

We hire good people to work for us.  We owe it to them to trust them to do the jobs they were hired to do.  As leaders, it’s our job to ensure that the organization is configured to allow that to occur and that there are as few road signs and traffic signals as we can get away with.  We don’t need false senses of security.  We need results.  Reduce the control points down to where people act as people, see the whole picture, and can act appropriately.  That’s the essence of agility, and where we need to be.

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


The post The Essence of Agility: Becoming Safer by Controlling Less appeared first on BigVisible Solutions.

Categories: Companies

TriAgile in RTP

Agile Artisans - Tue, 03/11/2014 - 02:00
I'm involved with a new conference coming to RTP in May. Come join us for TriAgile. We've got a great list of speakers and a good mix of topics. I'll be giving my Introduction to Agile talk. Andy Hunt, Cory Foy, and many other great speakers will share the stage.
Take advantage of the early bird pricing! I look forward to seeing you there.
Categories: Companies

Tracking Points vs. Tracking Hours

BigVisible Solutions :: An Agile Company - Mon, 03/10/2014 - 20:17

One of the questions that frequently comes up in the CSM trainings is:

“Is it better to track points or hours?”

The short answer is that either is fine. Both provide valuable information which can be helpful to the team. Whether you track both, or focus on just one of them is really dependent on the what the team feels provides them with a better understanding of their ability to meet their commitment (or forecast) during a sprint.

Tracking Points

If a team is tracking points in a burndown chart during a sprint, what they are paying attention to is the total number of story Tracking Pointspoints that belong to work they have committed to but that has not yet been accepted as potentially shippable by the Product Owner. In the sample, you can see that the team is working on a 10 day sprint and has forecast that they will be able to deliver 30 points of potentially shippable work. In this example, they are on Day 6 of the Sprint. Each day they have been updating the burndown and now have only 18 points which have yet to be accepted by the Product Owner as being potentially shippable. It is important to note that when you are tracking work this way, the burndown chart does not directly speak to how much work (labor) still has to be done. It only cares about how much is not yet potentially shippable. So, regardless of how many hours of labor it takes, the team is expected to meet their forecast and get the remaining 18 points to a state where the PO accepts it as being complete enough that it could ship.

Tracking Hours

If a team is tracking work in hours, what they are concerned with is the estimated total number of hours of work they expect to have to complete in order to meet their forecast and get all their work accepted by the Product Owner as being potentially Tracking Hoursshippable. In this type of burndown, the team is able to see how many estimated hours of work they have left, and how many days they have to do it in. In the example provided, the team began the sprint with 150 estimated hours of labor. Each day they have updated the burndown to show how many estimated hours of work remain. Because the team can add or remove tasks as needed during the sprint, they may have days when the work remaining is higher than it was the day before. This would probably indicate that they discovered some additional tasks which were required to complete the work they committed to. Likewise, they can remove tasks, so you may see drops in work remaining which are a mix of work having been completed and tasks that the team has removed.

The Scrum Framework does not specify a preference for tracking either points or hours. Most teams will find one more helpful in understanding their likelihood off meeting the commitment over the other. If you are using software to track your work, it will probably offer you the option of tracking either or both. It really comes down to what the team prefers.

IMHO – Coffee is for Closers!

In my own personal experience, I have developed a preference for tracking points over hours. The reason for that is that I was a Scrum Master on a project where the team continually struggled with their ability to deliver potentially shippable work. During the Sprint it was very common to see tasks added (which is what should happen if it needs to). Unfortunately, this happened in almost every Sprint and the additional work was very frequently significant enough that the team could not meet their commitment. The increased number of task hours would usually be the reason the team gave for not meeting a commitment at the end of the sprint. What was happening was that when the work was defined during Sprint planning, the team was not breaking it down to a point where they really understood what they were committing to. When this happens, the team should discuss how to become better at breaking down and estimating the work so that they do not over commit. In this particular case, that was not happening. Burning down the work indicated that the team was actually getting work done each day, and every day we were able to see the gap between our Coffee is for Closers! remaining capacity and the labor that was estimated to be required. The problem was, with this particular team, on this particular project, the fact that they were working really hard was not getting us any closer to meeting a forecast or delivering work which was accepted as potentially shippable. It may sound harsh, but there is no award for effort in Scrum. If the work is not done, it is not done. And at the end of the Sprint, no matter how hard the team has worked, they will have met their commitment (forecast) or not. Work will be in a state that is potentially shippable, or it will not. You can’t deliver unfinished product to your customer and ask to be paid because you worked really hard. (If you do have a customer like that, be VERY nice to them.) In Scrum, the goal is potentially shippable increments of work at the end of each Sprint. Focusing on this is why I (personally) tend to favor tracking points, but as I mentioned above, either is fine and both is even better.

Watch Dave Prior bring it home – go on press play.

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


The post Tracking Points vs. Tracking Hours appeared first on BigVisible Solutions.

Categories: Companies

AngularJS e2e testing using ngMockE2E

Xebia Blog - Sat, 03/08/2014 - 11:10

For our project we needed a mock http backend that we could instruct to return predefined responses so we were able to e2e test our full application without having a 'real' backend. This way we do not have to account for any state in the backend and can run our tests in isolation.

  • Reuse the mockdata object created for our unit tests
  • Reuse the config object in which we define the backend endpoints
  • Have little or no impact on the production code

The solution

First thing that is required is a second module that depends on your application's ng-app module and on ngMockE2E. So say your ngApp is called 'myApp' you start by defining a module myAppE2E:

angular.module('myAppE2E', ['myApp', 'ngMockE2E']);

This wrapper module will be responsible for instructing the ngMockE2E version of $httpBackend what to respond to which request. For this instruction we use the run method of the angular.Module type:

angular.module('myAppE2E', ['myApp', 'ngMockE2E']).run(function ($httpBackend, $cookies) {
  // let all views through (the actual html views from the views folder should be loaded)
  $httpBackend.whenGET(new RegExp('views\/.*')).passThrough();
  // Mock out the call to '/service/hello'
  $httpBackend.whenGET('/service/hello').respond(200, {message: 'world'});
  // Respond with 404 for all other service calls
  $httpBackend.whenGET(new RegExp('service\/.*')).respond(404)

As you see we created 2 testable scenarios here: 1 successful call and 1 failure scenario. Note that the failure scenario should be defined after the success scenario as the failure scenario has a more generic selector and would handle the success scenario as well. This is also the point where you can inject any objects used in your 'myApp' module such as a config object or a mockData object.

Now we have our module we need some non-intrusive way of injecting it into our index.html. For this we chose processHtml. We added the following section to the bottom of our index.html:

<!-- build:include:e2e e2e.html -->
<!-- /build -->

This section is replaced by the contents of the e2e.html file when processHtml is run in e2e mode and left to be in all other modes. The contents of the e2e.html file are as follows:

<!-- We need angular-mocks as it contains ngMockE2E -->
<script src="bower_components/angular-mocks/angular-mocks.js"></script>
<!-- This file contains the myAppE2E module responsible for priming the $httpBackend -->
<script src="test/e2e/util/myAppE2E.js"></script>
<!-- Replace the original ng-app attribute with the myAppE2E module name so that one is run -->
<script type="text/javascript">
    $('body').attr('ng-app', 'myAppE2E');

Now all that is left is instructing grunt to run processHtml in the e2e test mode. We first need to add the config to the initConfig section. Here we tell it to use index.html as input and create index_e2e.html as output:

    processhtml: {
      e2e: {
        files: {
          '<%= %>/index_e2e.html': ['<%= %>/index.html']
// snipped of all sorts of other config

Next we simply enhance the (yeoman generated) e2e task to run procssHtml:e2e before running the server

 grunt.registerTask('e2e', [
    // Simply add the task:

There you have it. No when you start grunt e2e and go to index_e2e.html you will have full control over the http responses and can write e2e tests that do not require you to take into account any state of the backend.

E2E mode - but no tests

Every now and then it is useful to be able to test the complete application in isolation without running the e2e tests. We created a special grunt task for this that behaves like the yeoman default 'server' task but with the ngMockE2E module running. This way, whenever you change a resource in your project it is processed immediately and you can see the results by refreshing instead of restarting the e2e task

  grunt.registerTask('e2enotest', [
Categories: Companies

Make It So… If Only Software Project Management Were That Simple

Agile Management Blog - VersionOne - Fri, 03/07/2014 - 11:58
What if you could successfully execute your software projects like Captain Jean-Luc Picard of the Starship Enterprise just by commanding, “Make it so?”

What if you could successfully execute your software projects like Captain Jean-Luc Picard of the Starship Enterprise just by commanding, “Make it so?”

Sounds silly, doesn’t it? Yet many traditional command-and-control organizations think they can work this way.

Manager types go behind closed doors and through a series of many meetings come forth with “The Plan.”  The plan directs what is to be done, how it is to done, when it is to be done, and by whom it will be done.  The software developers who must implement the plan are informed of the plan and directed to “Make It So.

Almost immediately it seems a question will be raised with the realization of, “oops, that was not considered…  it is not in the plan.”

But, the Project Manager’s job is to create and then deliver based on “The Plan.”  They will be evaluated based on that ability.  Their performance and success is measured by variances to the plan and they report these variances every month to their superiors.  As is typical with human behavior, it does not take long for a savvy Project Manager to realize that, “hey, if I want to keep my job, or better yet, get a good raise or promotion, I better not have variances.”  Variances to a plan are bad.  So the project management function seeks to control and, thus, essentially prevent change.  Change becomes a threat to success of the plan.

So, you must follow “The Plan” and stay on schedule and on budget – deliver the hours and the planned activity and events. 

But, the Customer wants everything they asked for, so you must deliver all content as well.  No, they cannot add anything that will change the plan. 

If the developers cannot stay on task as defined, they simply must work harder and longer because “The Plan” must be good.  Then they must explain in detail why they could not accomplish what they were told to do within their budgeted hours.  Just Make It So.

Waterfall project management wants fixed schedule, budget, and content.  Actually what they really want is that big raise for demonstrating how great their plan was and how well they controlled the project through the plan.

If this project is actually well understood up front and what’s to be accomplished is pretty stable, then this approach may actually work.  Project managers are smart people too, and they can effectively apply experience and judgment to make good plans under the right conditions.  Some industry is very heavily regulated and only a very precise and specific requirement is acceptable.  This approach can work well and, if it does for you, then great…. Make It So

But, what if the software product must evolve to changing conditions and needs?  Today’s rapidly advancing technology means end-users are increasingly fickle about what they want.  Many agile software project management products now are being provided to model business processes and interactions, either for internal or external customers.  These processes are under pressure to constantly change and improve meaning that the supporting software must also change.  Companies cannot maintain a competitive edge unless they change and evolve rapidly.  Software projects must be prepared to do the same.  Does it really make sense to tell your customer they cannot have the thing they discovered they really need now because it was not in your plan you made months ago?

Like science fiction, plans rarely mirror actual reality.  Trying to fix schedule, budget, and content is a real challenge for a number of software projects in organizations today.  In reality, one of these parameters must be allowed to flex.  End-user software is very hard to define up front.  Users often do not know what they want, and even when they think they do, they quickly evolve to need something else.  Plans must be able to adapt and yet still provide the business with the insight that it needs to manage teams effectively.

This “Make It So” approach must evolve and, with it, the behaviors of project management and the measurements of project/plan success.  Even really good project managers cannot control the future.

Maybe it is time to “boldly go” and explore a new “agile software development” approach – one that provides immediate visibility into the health and status of the project real-time, and readily allows for a changing parameter (content, schedule or budget) to be understood immediately. 

What do you think?


Categories: Companies

Innovation and 3 Levels of Product Ownership

TargetProcess - Edge of Chaos Blog - Thu, 03/06/2014 - 21:10

In a recently published article, A Product Owner’s Syllabus,  I shared how we educate product owners in our company. A product owner’s job requires competence in a number of domains, as it turned out. There’s one more consideration that I want to highlight. It’s rather related to the environment where this product owner works, not to personal skills or knowledge. Sometimes, though, it’s quite hard to draw the distinction between personal skills and how those skills are influenced by the environment.

3 Levels of Product Ownership

Product owners can act on the following levels:



Mix of innovative and market-driven

Why is it important to single out these levels  prior to doing drills in narrow disciplines included to the PO syllabus? This helps the trainees realize the high-octave “why” of this work. They say that philosophy is the mother of all sciences. In the same fashion, knowing the very reasons of why a product exists at all is the necessary first step. This knowledge and reasons are very product-specific.  That’s why I’m skeptical about all kinds of “certified” courses, because attending a course and taking part in abstract drills (such as the ones brilliantly mocked at in here) will not turn anyone into a mature product owner overnight. To me, the best credentials for a product owner would be the history of the product that this person owned or managed, at least for some time, and the thinking that stood behind their decisions. There’s no better learning than by doing.

Just as in my recent post, where I anchored our evolving as a company with the way we do visual process management, I will look back at the history of our product yet again. We’re cool big guys, because we can look back as far as 10 (!)  years ago. Targetprocess 1.0 was launched in 2004. Targetprocess 2.0 was released in 2006. Targetprocess 3 came on the scene around 2012-2013. The 1.0 version was the minimal viable and marketable software for agile project management. Targetprocess 1 had 7 releases, from 1.0 to 1.7. Targetprocess 2 had 24 sub-releases, from 2.0 to 2.24. With Targetprocess 3, we released the version 3.0.11 last week, and the next release will be 3.1.

The Market-Driven Suite and Innovation

Looking at the releases from 1.0 — 1.7, and 2.0 — 2.24 (click the hyperlinked words above), one can draw some interesting conclusions. Targetprocess progressed with the agile movement and with what the market wanted( I wish we had a decision sequence timeline to track this better).  The 1.0 version appeared as a result of market-based thinking, because agile was a rising new trend back then, and our product owner and founder (who has the project management background) wanted to do a decent software for agile project management. Then, with time, the 2.0 version was released. This was a re-written software with completely new UI. The product owner sensed that the product needs a robust core and an improved UI, before any new features could be added. That was a strategic market-based decision. Then after about 8 years of following the market, the product owner hits the level of innovation with Targetprocess3. It is indeed an innovative project management software as it brings along a new paradigm in visual project management. I do not intend to go too deep into praises, I just want to show with this story that it takes 8-10 years for a product owner to become mature and operate on the level of innovation. Some product owners never get to this level. They implement the features that make their product more appealing to users, to outperform the competitors, or both. There’s nothing good or bad about it, just the way it is. It’s quite rare nowadays that a completely new product comes as “innovative”. Start-ups are mostly busy discovering smaller niches in the established market and filling them in.

A Basic Drill for Newbie Product Owners

Well, a product owner may or may not reach the innovation level. Let’s get down back to earth. I have this list of questions ready for trainee product owners to help them exercise their minds in product-based thinking as they consider implementing new features:

How often will people use this new feature?
How many people will use it?
Will this feature address any particular pain of users?
How it will help users save their time, if at all?
Will it make any difference, or will users be just as fine without this feature in the product?
Will this feature make the product easier-to-use or more complex?
Will it help bring new business, or is it meant for established users, mainly?


Formulating such questions can be a good exercise at an internal company training. The road to success starts with one first step, and this simple drill might be a nice first move in a career of a product owner, who might become an Innovator some day.

Related articles:

What Comes Next In Your Product?

3D Backlog Management

Product Development: Drive or Hitchhike?

A Product Owner’s Syllabus

Categories: Companies

B The Change: We Are A Force For Good

Rally Agile Blog - Thu, 03/06/2014 - 06:57

Rally believes that for-profit business can -- and should -- be a force for social good. That means we join companies like Ben & Jerry's, Patagonia, Method, and Seventh Generation in measuring business success by the triple bottom line: people, planet, and profit.

Rally is part of a growing community of nearly 1,000 Certified B Corporations from 32 countries and 60 industries, working together toward one unifying goal -- to redefine success in business as being not just the best in the world, but the best FOR the world.

Rally just completed its third, rigorous B Lab assessment, demonstrating our positive impact on community, employees, and the environment. The B Corp model helps us benchmark that we are living up to our own mission and that we push it even further.

What makes Rally a Certified B Corp? Here are a some highlights:

  • Giving back to the community. In 2013, following our successful IPO, Rally donated $1.4M of founding equity to charitable causes and created the Rally For Impact Foundation, which enables engineers to apply their skills and expertise for positive social change.
  • Providing free Agile education. Rally is working with innovative social impact organizations such as Rocky Mountain Microfinance Institute, where employee volunteers provide Agile coaching, training, business planning and team facilitation. In 2013, our employee experts also delivered “Act Like An Agilist” courses to social entrepreneurs at the Unreasonable Institute and Impact HUB Boulder.
  • Treating employees well. We were honored in 2013 as "Best for Workers," scoring in the top 10% of all Certified B Corporations for our positive impact on the people of Rally.
  • Paying People to Give Back. Our culture of giving encourages employees to spend 1% of their paid time volunteering, as well as giving back to their community on their personal time. As a result, in 2013 Rally employees contributed nearly 4,700 volunteer hours, or almost 600 worker days.
  • Encouraging volunteerism from day one. Beginning this month, when new employees go through Rally’s onboarding “boot camp” they spend two hours volunteering.
  • Shrinking our carbon footprint. Rally’s products are primarily deployed as Software as a Service (SaaS), which minimizes the creation or shipment of physical goods and optimizes the energy-efficiency of modern data centers.
  • Recycling and composting at scale. At our office headquarters in Boulder, Colorado, where we employ about 60% of our staff, we’ve partnered with internationally-recognized nonprofit Eco-cycle to recycle and compost 74% of our waste.
  • Getting to work with pedal power. Rally’s Boulder and Denver offices have a large bike-to-work population, and we offer all Colorado employees a company-paid EcoPass for public transportation.

As a Certified B Corp, Rally supports the movement for business to play a leading role in providing social and economic benefits to the world while delivering great products and services at a profit. Values-led businesses like Rally deliver shareholder value, while building trust among our customers and partners that we are in service to the global community.

We have a shared responsibility: we are collectively striving for shared and durable prosperity. Let’s B the Change.

Geri Mitchell-Brown
Categories: Companies

End of an era in my garage

Xebia Blog - Wed, 03/05/2014 - 20:27

This weekend I was forced to throw away a cardboard box. So what, I hear you think and I agree, but it being Sunday and me being in a hazy reflective Sunday afternoon state of mind (nono, no alcohol yet) and the box being the specific cardboard box it is (or rather was), I started thinking of the box’s significance for the future.

This is a picture of the cardboard box in question in it’s final state just before it got thrown into the recycler.
End of an era in my garage
As you can see it’s got a large sticker saying ‘Oracle’ above the word ‘KABELS’ written in my clunky handwriting. The word kabels doesn’t really matter, it just indicates the box was used to hold various lengths of electrical wire. Next to the Oracle sticker and the kabels text you’ll see a partially torn label from ‘Donelly Documentation Services’ in Ireland. It is in fact the box that was used to ship my very first set of Oracle manuals (for release 6 of the Database and probably 3.0 of Forms and more contemporary tools) in April 1992. Since that time the box used to hold manuals for consecutive releases of Oracle products stored in the trunk of my car. I used to take them with me to customers on various assignments.
Later I left Oracle and the box was used in two removals (it was of remarkably sturdy material) and ended in my garage holding bits and pieces of electrical wire.
Last Sunday I dragged it of a shelf and finally it’s corners tore spilling cables all over me and the garage floor. Exit box.

This is getting into a long winded intro, I know but there is an interesting similarity between the box and the changes in the tools I use in my professional life. After starting as an Oracle specialist I worked on Java software which became Oracle software later of course. Last Sunday I realized I was writing Java-ish software again for the first time in about a year. Android, but still.
I haven’t been using any of the software I grew up with for quite a while now. Relational databases are being replaced by key-value stores and even flat files. JEE servers changed into Spray and Akka. Scala and functional and reactive programming constructs rather than object oriented Java and its bolted-on lambda extensions. Angular-JS instead of, hey wait a minute, that looks like a fat client all over again (wondering what’s going to happen to it). Server software I work with is easy to install, unpacking a zip file instead of 500+ pages of manual guaranteed only on an outdated Linux version. Modern software runs on simple Linux boxes instead of high end hardware with 7 digit price tags. New and innovative solutions replace software with slow release cycles. Open source is definitely leading the industry.

I wonder, does the end of the box forebode the end of a whole class of software? And like the cardboard box, will some bits and pieces come back in other products? I’m just hoping that it won’t take 22 years to get rid of the last generation of software.

Categories: Companies

Is Your Agile Team Formula One or NASCAR?

Rally Agile Blog - Wed, 03/05/2014 - 14:00

This incredible video of a Formula One pit crew in action has been making the rounds on the Internet lately. Have you seen it? The crew performs an entire pit stop in under three seconds, with no errors, working in perfect synchronicity -- like a “pit stop ballet.” Go ahead and watch, we’ll wait ... (it’s only 56 seconds, and safe for work.)

Watching this video got us thinking about the performance of Agile teams (hat tip to Agilista JessK.) Rally knows a little something about team performance thanks to the work of Larry Maccherone, Director of Analytics at Rally, and his Software Development Performance Index.

Using real, non-attributable data from the performance of nearly 10,000 teams, Larry’s analytics team looked at four dimensions of Agile team performance: productivity, predictability, quality, and responsiveness. What they found is pretty incredible evidence for how to optimize your Agile team performance.

To demonstrate, let’s use the F1 crew as an example. Each F1 pit crew mechanic has a distinct role, and performs only one job. In Agile terms, you might say that this crew has extremely low Work in Process (WiP.) And on an an Agile team, having fewer work items in process means that each item gets done faster. The amount of time that a work item spends in process is a measure of responsiveness. So lower WiP means faster time in process, faster time to market … and in the case of the pit crew above, highly responsive pit stops.

In Agile, teams with poor control over their WiP take nearly twice as long (see Time in Process on the Y-axis, above) to complete their user stories as teams with low WiP. This makes intuitive sense: as with the F1 mechanics, the more focused you are on just one thing, the faster you'll get each one done.

Lowering your WiP can have benefits besides responsiveness: teams with the lowest WiP have 4x better quality  than teams with the highest WiP. When your job is to affix a tire to a car that’s going to drive more than 200 miles per hour, well … quality really matters.

But performance like that of the F1 crew comes with some costs. Though teams with low WiP may cut their time in process in half, and have one-quarter as many defects, they also have 34% lower productivity.

In Agile, productivity is measured by the number of user stories and defects completed in a given time period. Take a look at this NASCAR pit crew as an example.

NASCAR races allow a limited number of pit crew members "over the wall” during a pit stop, so each mechanic must be more productive. Changing a tire takes about 5 seconds, and each mechanic has to change 2 tires. While this crew may not seem as responsive as the F1 crew (its Time in Process is 13 seconds vs. under 3,) it’s much more productive.

Speaking of numbers: did you happen to count the number of mechanics on that F1 crew? There are a whopping 21 of them, standing around waiting for their car to pull in. By contrast, the NASCAR pit crew is limited to 7 mechanics. (The recommended size of an Agile team is 7 ±2.)

So what does this all mean?

  • If your WiP is high and you’re at risk for missing a market window, then drive your WiP as low as possible by focusing on just a few things and getting them to market faster. In other words, make like an F1 pit crew.
  • If your WiP is already well-controlled, however, consider your economic drivers. For example, if productivity drives your bottom line, don’t push your WiP too low. Instead, take more of a NASCAR pit crew approach. Balance is key.

Hungry for more?

  • We’ve got our own videos of Larry Maccherone himself, explaining the team performance metrics.
  • You can download the whitepaper if you prefer reading to watching; you can learn about the dimension of predictability in here, too.
  • Lest you get carried away with the weight of performance metrics, make sure you check out the Seven Deadly Sins of Agile Measurement.
  • Finally, stay tuned: if you're a Rally user, these metrics will soon be coming to a dashboard near you.

Jenny Slade
Categories: Companies

Our Evolution of Visual Process Management

TargetProcess - Edge of Chaos Blog - Wed, 03/05/2014 - 10:43

I’ve poked around the subject of visual process management in my previous articles, accentuating the complexity and non-linearity of software production process, and how a traditional Kanban board fails to visualize the diversity of organizational contexts and workflows.  With that in mind, I’ve introduced a concept for a universal visual process management system that is capable to embrace this diversity and linearity on one screen, with flexible zoom-ins and switches, and called it Multiban.

The Limitations of Kanban Board

Many software development teams suffer the limitations of Kanban board, at one point of their evolution or another. When a company grows, the scope of work grows as well, the structure of the company and of the teams, that it is comprised of, are changing, and what if one Kanban board is not capable to accommodate those changes? What if a large company is working on a suite of products, and a 1 team-only Kanban board cannot show the bottlenecks that are out-of-the scope for this team, but still influence its work? Or, what if the 1 team-only WIP’s are not relevant, because a suite of products is a sum of components, where each team’s work is a component of the whole product, and WIP’s and value streams have to be balanced on a wider scale, beyond the scope of one team-one project board?

We had to find answers to such questions. In 2012, Michael Dubakov published the Our Development Process: 50 Months of Evolution article. The changes that have occurred over 2012-14 are not covered there, but it still shows how our needs in visual process management were addressed in parallel with the changes in our company setup. Keep in mind that we are a very special company. We develop Targetprocess, agile project management software, since 2004, and we have an advantage because we are free to choose how to shape our product to make it respond to the changing needs and structure of our organization better. Over the last 5 years, we’ve been consistently working to make our tool more visual and more powerful. I will single out the major landmarks.

2009: Switch from Scrum to Kanban

In 2009, we switched from Scrum to Kanban. By 2009, we’d been doing iterations for 3 years, and iteration development worked great when Targetprocess was a young product that needed to gain the critical mass and stay alive. Then, we realized — and that coincided in time with the uprise of Kanban — that we’d be better off reaching our goals as an organization if we practice development with Kanban. If you’re interested, here’s an in-depth story of the reasons and the production context that we had back in 2009. With our hands-on attitude, we didn’t linger with it, and implemented Kanban support in our project management tool. That’s how our Kanban board looked back in 2009 (one team-one project):

TP Kanban board 2009

We implemented this Kanban board to cater both to our own needs, and to the needs of our customers.

2010-11: Kanban is not enough. How about TeamsBoard?

While the major reason for our move to Kanban in 2009 was the change in the product development dynamics (the product matured, and we needed to switch to the “add features” mode), the major change in 2010-11 was the switch from one team to many teams, as we realized that this setup works better for the “add features” mode. The count of feature teams is not fixed, it changes depending on which features we’re doing at the moment. So, we felt the need to visualize the work of many teams on one board. Hmm. That’s not what a simple Kanban board was able to offer us. That’s why, as hands-on as we are, we poked around and came up with what we can now call the forefather of Targetprocess 3. Take a look at TeamsBoard, edition 2010:

TeamsBoard 2010

This board doesn’t look too fancy now, in 2014, but back then it was surely a step ahead compared to a simple Kanban board. One can see backlog, and work in progress for many teams. If some states had their WIP limit exceeded, the TeamsBoard would show it. In the screen above one can see that WS team had the bottleneck with 3 bugs and 1 user story resting in the Coded state. Then this work of testing could be shared with the other two teams. The TeamsBoard also allowed zooming in on each team, and what they do, by person.

2012-14: Targetprocess 3 and Fine-Tuning Process Visualization

Then, as we realized that sky is the limit, and visualization has enormous potential for project management, and for our own needs, we moved forward with the concept of the tool where anything can be visualized, depending on the changing dynamics and goals of a company.  The fundamental idea is to offer a flexible tool that adapts to any process and follows any organizational changes. The other fundamental principle  is the switchability of visualizations. We do not have stakeholders who tell us what to do and what to implement next. Our feature teams and our customers are the stakeholders. They tell us where else they need flexibility, and our backlog is formed based on those needs. We run recurring UX Process Visualization sessions, to see where else do we have yet to make room for more visual flexibility. We stepped aside from the traditional Kanban as the visual process management system long ago, and what we are now having is Multiban a visual process management system that supports any development process, for any number of teams and any number of projects, with cross-team and cross-project planning, using timelines for roadmapping, views as reports, etc. This screen from Targetprocess 3 is related to the good old Kanban of 2009 only by its board-ish looks, while in reality it is a switchable slate of views, zooms and perspectives.

Work by Teams in Targetprocess 3

Why Multiban makes sense?

It’s time to say a few words about Multiban now. Perhaps, the fastest way to explain how Multiban differs from Kanban is to use a metaphor. Multiban can be compared to the 17-inch interactive screen as in Tesla luxury electric cars. This awesome screen is a one-spot customizable dashboard for media, navigation, communications, cabin controls and vehicle data.  Multiple Kanban boards for one suite of products (or a related suite of features, as in our case) can be compared to putting many touchscreens in the car, or even to using plastic controls for each of those functions. Would a driver feel more comfortable using one smart touchscreen? Or many simple screens? Or many knobs? It depends. For one thing, no doubt, the super-fancy touchscreen would require a learning curve. If a driver is OK with various controls, and if they do not depend on each other, then probably the car and the driving will be OK. Switching back to knowledge work:  too many things are interrelated in software development, and losing track of those connections can have a bad impact on the way the work is done . It’s hard to keep everything in mind, and use visual board as a polished parade version of a development process. Multiban, as the visual process management system, is presented by a set of views, reports, controls and boards that comply with any diversity, and any complexity of workflow, or organizational structure.  Targetprocess 3 is the only digital tool that supports Multiban at the moment. The concept of Multiban is the by-product of our organizational evolution, which dictated the need for evolutionary changes in our visual process management. Now we are ready to share what we’ve learned and implemented with other organizations that have been evolving, or will be evolving, in a similar fashion.

Related articles:

Kanban as Multiban?

Stuck with Kanban? Consider Multiban

Categories: Companies

Using Dissent to Challenge Our Own Assumptions

NetObjectives - Tue, 03/04/2014 - 18:44
There has been a fair amount of discussion regarding Ron’s thoughtful blog on SAFe. I want to shift the discussion from what Ron said to what we can learn.  I do not intend to respond to Ron's entries directly.  What I will say is that Ron is very intelligent, very experienced and truly wanting to make a positive difference in the community. He is one of my most respected thought leaders, even...

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

How LeanKit became ‘the go-to place to know what’s going on’ at Emma

The link between business agility and business success is clear. In the face of fierce competitive environments and ever-emerging customer requirements, businesses must ensure they can adapt to change rapidly and efficiently in order to stay relevant. Yet as business leaders constantly adapt their strategic roadmaps to address changing priorities, keeping the entire organization in […]

The post How LeanKit became ‘the go-to place to know what’s going on’ at Emma appeared first on Blog | LeanKit.

Categories: Companies

Why Limiting Your Work-in-Progress Matters

If you’re a fan of Jim Benson and Tonianne DeMaria Barry’s Personal Kanban writings, you’ll know that they have two basic rules: 1)     Visualize your work 2)     Limit your Work-in-Progress Being relatively new to Kanban, the first rule instantly made a lot of sense to me – particularly in the context of using LeanKit. Being […]

The post Why Limiting Your Work-in-Progress Matters appeared first on Blog | LeanKit.

Categories: Companies