Skip to content

Feed aggregator

Launching this month: DFW Scrum Tech Edition

DFW Scrum User Group - Sat, 01/14/2017 - 16:49
When I travel to agile events, I love telling people about our community. The agile community in Dallas is incredibly strong. In a typical month, there are at least 4 different meetup groups hosting events, and the number continues to … Continue reading →
Categories: Communities

A Light Bulb Moment

A few months ago Michele of Sliger Consulting, Inc. asked about my first Agile Light Bulb moment, I've had a few of them but one that easily came to mind was this one with the Washington State Appellate Clerk court case management systems people back in 2005.

In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful.
"My light bulb moment was during the product demo in the Sprint Review Meeting, when the state of Washington Appellate Clerk of Court told me he and the courts had been waiting 20 years for the feature that our team had just delivered. In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful. He later sent me the requirement spec for the 20-year-old feature and it read just like our epic story and its children we discovered. Yes, this was a completely different system than the previous retired system - yet it had the same customer needs. We had transitioned from a deadlocked in analysis paralysis development group to a Scrum team in under 3 months, delivering into production every month new features, bug fixes, and tested working software."  -- David Koontz
See other Light Bulb Moments at Sliger Consulting Light Bulb Moments

Have you seen in other collections of Light Bulb Moments?  Please comment below.

Categories: Blogs

The Five D Value Stream – Discover, Decide, Detail, Develop, and Deploy

NetObjectives - Fri, 01/13/2017 - 11:32
The Five D Value Stream – Discover, Decide, Detail, Develop, and Deploy   A software value stream shows how a software change flows from the discovery of an idea to it deployment.  We show how a simple model of a value stream can be used as the basis for more complicated models in larger systems and how doneness focused processes and agile at scale align with the model.  The 5 D’s Let’s...

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

What Is and What Is to Be: Minimum Business Increments and Stories

NetObjectives - Fri, 01/13/2017 - 11:10
When looking at changes to be made to a system, one can look from the system's perspective (what changes need to be made) or one can look from the workflow perspective (how the bundles of changes to be made). Both views are important. One shows what is “to-be”; the other shows how you are going to get there. Change in System Here’s an example showing where in a system a change is being made....

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

Why Student Developers Choose Axosoft

About SCRUM - Hamid Shojaee Axosoft - Wed, 01/11/2017 - 19:01

Axosoft is dedicated to helping the development community advance by providing quality tools for developers, amongst other initiatives. We know that in order for our community to grow, we need to ensure the next generation of developers like you have the support and tools you need to advance your skills.

That’s why we provide Axosoft, our Scrum project management software, and GitKraken, our cross-platform Git GUI clientfree for students!

So, let’s talk about why students love using Axosoft, and how you can get a free Axosoft student account!

Why do students use Axosoft?

Student developers are almost always required to do a capstone project, research project or some sort of group project. Because students oftentimes choose to take online classes, or have to do work remotely (meaning, at home, at the library, or anywhere outside of your classroom), collaboration software is essential to getting these projects completed successfully.

UAT students use Axosoft UAT students using Axosoft | Photo by Jake Turocy

Students need to be able to communicate and sync up on projects regardless of location. This is where hosted Scrum project management software comes in handy!

“Axosoft is a great tool for keeping communication flowing through development teams.”Game Developer Student, UAT Game Studios

Axosoft empowers students to share team goals, assign tasks and keep team members accountable for their work.

Why learn Scrum?

Many schools like the University of Advancing Technology (UAT) use the Scrum framework and agile methodologies to teach their students best practices for software development. Scrum and agile have become increasingly popular amongst tech companies, so student developers with an understanding of these concepts have a huge advantage upon entering the workforce.

We’ve created Learn Scrum in Under 10 Minutes, a video which has now been viewed over 1.5 million times (making it the most popular Scrum learning video). It’s used by many Computer Science professors across the world to teach students Scrum. Moreover, our site is dedicated to helping developers learn Scrum in 6 steps.

Professors at UAT and other universities see great success in teaching students Scrum while also having them use Axosoft.

How do students use Axosoft?

In general, students find it easy to follow our tutorials and Scrum learning resources to quickly get started working on their projects in Axosoft.

UAT students use Axosoft UAT students use Axosoft | Photo by Jake Turocy “All students enrolled in the UAT Game Studios track their weekly sprint progress using Axosoft.”Game Developer Student, UAT Game Studios

Students at UAT Game Studios are required to submit screenshots of their Axosoft Release Planners and team burndown charts. This helps students and professors determine each team’s velocity of game production.

It’s easy to know if your project can be completed on time with Axosoft’s custom dashboards, which include burndown charts, velocity calculations and projected ship date widgets.

axosoft scrum dashboard

The kanban board in Axosoft allows students to visualize tasks easily, and know who’s working on what. Plus, you can simply drag and drop items through the workflow steps.

There are many more features that make Axosoft a great, free Scrum project management tool for student developers, such as release planning, task prioritization, team capacity calculations and work logs!

How do I get a free student account?

It’s easy to get started with a free Axosoft account for one year! Simply click below to create your free account.

Create Free Account

Categories: Companies

CMMI Institute Publishes A Guide to Scrum and CMMI

Scrum Expert - Wed, 01/11/2017 - 18:02
Organizations that attempt to scale agile need significant structural changes and support. CMMI helps organizations reap the benefits of agile and scale its adoption across teams, divisions, and the global enterprise. CMMI Institute has released “A Guide to Scrum and CMMI: Improving Agile Performance with CMMI” to help users adopt and implement CMMI to improve performance in agile organizations. In 2015, CMMI Institute estimated that over 70% of CMMI appraised organizations reported using agile. Agile organizations struggling with issues of performance are increasingly turning to the CMMI for proven results. The CMMI Institute developed “A Guide to Scrum and CMMI: Improving Agile Performance with CMMI” as a roadmap to successfully adopt and implement CMMI and agile together. The CMMI provides a framework or map of “what” a high-performance organization must do. Agile provides particular approaches that prescribe “how” to do it. As methods and techniques are adapted and evolve, the CMMI provides the foundation on which organizations can iterate or tailor their techniques in a way that is appropriate to the dynamics of their business environment. The discipline, organizational learning, and consistency provided by the adoption of CMMI supports organizations in making their agile implementation even stronger and more effective. A Guide to Scrum and CMMI: Improving Agile Performance with CMMI is now available for download and use. For more information on CMMI and agile and to download the Guide, visit
Categories: Communities

Cycle Time and Lead Time

Our organization is starting to talk about measuring Cycle Time and Lead Time on our software engineering stories.  It's just an observation, but few people seem to understand these measurement concepts, but everyone is talking about them.  This is a bad omen...  wish I could help illustrate these terms.  Because I doubt the measurements will be very accurate if the community doesn't understand when to start the clock, and just as important - when to stop it.

[For the nature of confusion around this terms compare and contrast these:  Agile Alliance Glossary; Six Sigma;; Lean Glossary.]

The team I'm working with had a toy basket ball goal over their Scrum board...  like many cheep toys the rim broke.  Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy.  The team used "Command Strips" to mount it but they didn't hold for long.

The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart.  Not cause and effect, but correlation; have you ever stopped to think what that really means?  Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?

I asked the head person at the site for advice, how could we get the goal mounted in our area?  He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips.  Yes, great minds...  but what about getting fired after putting holes in the walls scares one from doing the right thing?  How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?

The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done.  That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation).  Are you starting the clock?  It's Dec 7th, lead time starts when Mike agreed to the team's request.

The team was excited, it looked like their desire was going to be granted.  Productive would flourish again.

Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor.  There were about 4 of these meetings each very short and not always the same people.  Team members would come up to me afterwards and ask...  "are we still getting the goal?"... "when are they going to bring a drill?"...  "what's taking so long?"

Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill.  It took about 20 minutes.  Basketball goal mounted (Dec 13th) - which clock did you stop?  All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).

I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered.  In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.

In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary).  And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount  the goal (100 minutes).  Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.

Lead time:  Dec 13th minus Dec 7th = 5 work days
Cycle time:  hash marks //// (4)  one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill;  total 100 minutes

Lead Time 5 days; Cycle Time 100 minutes
This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements.  How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy.   Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time.  The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.

But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy?  Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?


Well it's January 5th and this example came up in a Scrum Master's Forum meeting.  After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time.  Maybe this is much harder than I thought.  Turns out I'm in the minority of opinions - I'm doing it wrong!

Could you help me figure out why my view point is wrong?  Comment below, please.

LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time.  I see no 'per unit' in their definition of cycle time.  The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.

See Also:
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releases
Categories: Blogs

Free Retrospective Tools for Distributed Scrum Teams

Scrum Expert - Wed, 01/11/2017 - 15:00
Even if Agile approaches favor collocated teams, distributed Scrum teams are more common that what we might think. Many Agile software development teams are based on a virtual organization. This article presents some free online tools that can be used to facilitate retrospectives for distributed Scrum teams. You will find in this article only tools that are supposed to be used for free in the long term. We do not list tools that offer only a free trial based on duration or the number of retrospectives. We will also only mention the tools that have features specifically dedicated to Scrum retrospectives. There are many other tools that Scrum teams might use, from video conferencing platforms to online whiteboard software. Mentioning all these tools will result more in a book than an article. If you want to add a tool that fits these requirements to this article, just let us now using the contact form. Updates July 19 2016: added Fun Retro January 10 2017: added goReflect, ScatterSpoke, Scrum Toolkit IdeaBoardz IdeaBoardz is a free online team collaboration tool. It allows teams to collectively gather inputs, reflect and retrospect. It is especially useful for distributed teams. For Scrum retrospectives, you can create two types of boards: standard or starfish. More board options are available (pros & cons, to-dos) that could be also useful. You can edit the titles of the sections of your board. The interface seems very intuitive, but sometimes I ended up in some situations where I didn’t know [...]
Categories: Communities

System Design Canvas

Leading Agile - Wed, 01/11/2017 - 14:55

In a previous post about productivity patterns, I wrote about how I tried countless systems to improve my productivity. I tried everything from having a Franklin Planner, to using GTD, to Personal Kanban and the Pomodoro Technique. I asked myself why some methods worked and some did not.  Why did I abandon two systems when I knew so many others have been successful with them? Why has Personal Kanban worked for me for the last 7 years?  I started listing common traits and saw relationships and discovered patterns.  Not only are there three things I believe every system needs to work, I also see three things that are necessary to prevent you from abandoning that system.

Every personal or professional thing we do is part of a system or subsystem.  Those systems have both success and failure patterns.

Success Patterns

For a system (defined as a set of principles or procedures to get something done or accomplished) to be successful, you always need ritual and habit.

  • ritual is a series of actions or type of behavior regularly and invariably followed by someone.
  • habit is a regular tendency or practice, especially one that is hard to give up.  You need to be habitual with your rituals, as part of your system.
Failure Patterns

Early indicators that your system will fail include a lack of clarity, progress, or commitment

(Very similar to Mike Cottmeyer’s “Why Agile Fails)
  • Lack of clarity creates confusion and waste. Each step of a system should be actionable and repeatable. In order to ensure certainty around your system steps, write them down.
  • If you lack progress, you will lose momentum. If you lose momentum, you will lose commitment to the system.
  • Lack of commitment to the system results in you no longer using the system. You move on to something new to get the results you seek.
System Design Canvas

After I identified the patterns, I wanted to present a useful model to visualize the indicators that will, in time, cause the system to fail.  I decided to base my model on the Business Model Canvas by Alex Osterwalder.  Below you will see the five areas that need to be considered. Once complete, if you notice one or more of the sections is ambiguous or short on details, you should view that as a warning.  

System Design Canvas Template

Scrum Framework Success Patterns

By using the Scrum Framework as an example system, I completed my system design canvas.  Upon completion of the worksheet below, I can see if there are any “gaps” in the system.  As you may have guessed, there are no gaps, if Scrum is properly implemented and followed.  But if it was modified without expert guidance, a gap will become visible and provide an indication that the system is at risk of failure.

Scrum System Design Canvas

Because you may have a large organization where you are dealing with different kinds of dependencies, you may need to create “sub” system design canvases to account for organizational complexity.  Scrum may not be enough. Don’t worry. The same rules apply.

Free Download

Interested in testing your system or subsystems?  Download a free copy of the System Design Canvas and see if you are at risk of failure.  Because I am providing this under a Creative Commons Attribution-Share Alike 3.0 Unported license, I welcome you to download it and modify it to meet your needs.

The post System Design Canvas appeared first on LeadingAgile.

Categories: Blogs

Synergic Reading Lessons

Wondering what other books I should read concurrently with the philosophy of this book, Other Minds, on the mind of our alien ancestors. In chapter one Peter is already mashing up Ismael and Darwin, so I feel it appropriate to do a bit of mix-in myself. I'm thinking Seven Brief Lessons on Physics will add spice. To bad I recycled How to build a Mind at Half Price Books.

I've also got to read Coaching Agile Teams by Lyssa Adkins for work's book club. And I may mix-in a bit of LEGO Serious Play, because I cannot get serious about coaching - seems like a play activity to me.

Maybe I will devise a quadrant model of these books. A Venn diagram of their overlapping topics.

Categories: Blogs

Mean Time between Disruptions (MTD) a leadership Metric

A rant on Metric's I wish I had written...  so I'm going to just include it by reference and call it my own.

One thousand Words on Metrics

Here's a quote to get you even more interested in clicking that link...
ConclusionIn short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring.If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell?And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do?Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”? Well - will you look at that!  Yareev's even willing to apply his own metric to his work.  What a great example of a leader...
Let’s try that againNew metric (expiration = next subhead, privacy = public): I’m 0 for 1 on satisfying conclusions to this post.I’m hardly an expert on human behavior. If I were one, rather than being passive-aggressive and obstructive, I’d have a ready step to suggest to metrics-wanters, one that they’d likely find more desirable than metrics.Instead I have to talk myself down from passo-aggro-obstructo, by which time they’ve chosen what they’ll observe and the ready step I can offer is limited to encouraging them to observe the effects of their observation.Can you give me some better ideas?Here's my very special response to his request for comments.

   I'm wanting to +1 your whole rant, I'd like to nail it to the front doors, I'm thinking about a tattoo, but unsure where on my leader's body it should go...

   I have sometimes fantasied about asking the VP that want's a new metric, if it would be good for us to add one that measured their leadership of our group - I'll call this metric Mean Time between Disruptions (MTD).  MTD is calculated much like the old factory sign that said:
 "its been 1023 days since we killed someone at this factory, please be safe."   So let's start counting (I suggest in weeks) the time between a major disruption to the team.  For this basic metric we are looking at team formation dynamics (your familiar with Tuckman's Forming, Storming, Norming, Performing) and you Mr. VP desire the P word - but it comes after 3 stages of development beyond the F word).

   Let's start at the beginning and count weeks between Forming and ReForming.  You know like when you move a person on/off a team.  When you move the team's physical location, or when you give the team a new objective, then let's reset the clock.

   The metrics I've seen range from MTD = 0 to about 20 weeks for many teams I've worked with.  And Mr. VP says they desire persistent teams.

I would have put it on his site in the comments but I got a very dissatisfied error message from the system when I posted it... (wonder if he has a metric for failed comments?).

Agile in 3 Minutes  a podcast that discusses a journey toward agility (each episode in exactly 3 minutes).  I'm pondering... why does the magic number 3 come up in the Agile community so often?  Personally I feel it has to do with the Book of Armaments, chapter 2, verse 9 to 21; because 5 is right out!

See Also:
Team Metrics - Case Study
How could we measure Team Happiness?
Metrics for a Scrum Team  but don't confuse that post with Scrum Team Metrics which discusses the necessary and sufficient metric Velocity.
Do you really need a Project Management Office? (PMO effectiveness metrics)

Categories: Blogs

Rethinking Component Teams for Flow

Johanna Rothman - Tue, 01/10/2017 - 23:58

A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.

One of the (very sharp) fellows in the audience asked this question:

As you grow, don’t you need component teams?

I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams. And, then they have a little problem. They can’t find enough UX/UI people. Or, they can’t find enough database people. Or, enough writers. Or some other necessary role for the “next” team. They have a team without necessary expertise.

If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.

Some organizations attempt to work around the scarce-expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.

When you do that, you flow work through a not-complete team. You’re still flowing work, but the team itself can’t do the work.

You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has 12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)

When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person. Or, you’re waiting for an expert. (See CoD Due to Multitasking and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)

What can you do?

  1. Flow work through the experts. Instead of flowing work through teams that don’t have all the expertise,  flow work through the experts (not the teams).
  2. Never let experts work alone. With any luck, you have people in the team working with the experts. In Theory of Constraints terms, this is exploiting the constraint. It doesn’t matter what other work you do. If your team requires this expertise, you need to know about it and exploit it (in TOC sense of exploitation).
  3. Visualize the flow of work. Consider a kanban board such as the one below that shows all the work in progress and how you might see what is waiting for whom. I would also measure the Cost of Delay so you can see what the delay due to experts is.
  4. Rearrange backlog ranking, so you have fewer teams waiting for the scarcity.

Here’s the problem. When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.

Visualizing the work helps.

Flowing the work through the constrained people will show you your real capacity.

Needing component teams is a sign someone is still thinking in resource efficiency, not flow efficiency. And, I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.

If you can’t hire, you have several choices:

  • Have the people with the scarce expertise consciously train others to be ready for them, when those scarce-expertise people become available. Even I can learn some capability in the UI. I will never be a UI expert, but I can learn enough to prepare the code or the tests or the experiments or whatever. (I’m using UI as an example.)
  • Change the backlogs and possibly reorganize as a program. Now, instead of all the teams competing for the scarce expertise, you understand where in the program you want to use that scarce expertise. Program management can help you rationalize the value of the entire backlog for that program.
  • Rethink your capacity and what you want the organization to deliver when. Maybe it’s time for smaller features, more experiments, more MVPs before you invest a ton of time in work you might not need.

I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.

Categories: Blogs

Should the PMO go away?

Leading Agile - Tue, 01/10/2017 - 16:00

When I go in to do large scale transformations I’m invariably asked the question, “should the PMO go away?’  The reasoning is that going agile should get rid of all of the oversight, the Gantt Charts, the weekly status meetings, release scheduling.  The list goes on.

Before I address the question I want to give you some background as to what we typically see when we hit the ground from a coaching standpoint.  The company is in an ad hoc state. They may be delivering but it isn’t always on time.  Scope creep is inevitable in this environment as they schedule 3,6, and maybe even 12 month releases. As much as the teams try to be agile there are a number of processes in place to make sure the product actually gets out the door. There’s some release planning up front, expectations are set.  Development may occur in sprints but integration testing and acceptance testing lag behind. Sometimes it is so complicated to do integration testing it has to happen in a big time box towards the end.  The business becomes disengaged while development is off sprinting.  This process isn’t agile and if you did lay it out in a Gantt chart it would present very much like waterfall.

Now think about all the stage gates you have in your organization. Release planning sign off. Weekly change control. Release scheduling. Release sign off. Deployment planning. Deployment change control. Some organizations I’ve seen have 20 people on the phone during an overnight deployment.  So why is this? The answer is simple. Over time the organization has created an environment of mistrust. Promises have been broken. Buggy software has been delivered to customers. Fingers pointed; “Requirements were bad”, “Development is slow”, “Too many last minute changes.” A number of reasons have caused the need for the stage gates. Once a stage gate exists it’s difficult to remove.

To get the organization back on track we need to refocus on the 3 things that make up an agile process; backlog, team and working tested software.  In essence, clarity, accountability and measurable progress. In order to do this, we need governance, structure and metrics. These things will get us to a predictable state. Once we get predictable we can begin to rebuild the trust in the organization.

To get an organization back on track we need to focus on the 3 things that make up an agile process; backlog, team and working tested software.

The governance model must slice through the organization from the top to the bottom. In many organizations this will be in the form of at least 3 layers; Portfolio, Program, and Team.  The Portfolio layer will deal with the creation, definition and prioritization of themes and epics. The Program layer will create define, and prioritize features. The Team level is responsible for the implementation of the user stories derived from the features.  This governance model will further define the process flows to go from inception to deployment.

What I have briefly described here is an initial step towards a logically planned out transformation strategy. As you can see, in this first step we clearly define a structure and a governance model that leads to a predictable process. We can’t just teach agile practices and hope everybody sees the light. There are a number of manual orchestration activities in the organization to keep everything moving forward. As the organization moves further along the scale towards a more decoupled system of delivery then the manual orchestration will diminish. I refer to this manual orchestration and stabilization processes as scaffolding. As manual orchestration diminishes the scaffolding can begin to come down. It is important in your transformation to identify the scaffolding and plan as part of your future transformation efforts to remove it.

Once we get predictable we can begin to rebuild the trust in the organization.

So, “Should the PMO go away?”  Not in this scenario.  Some part of the organization needs to facilitate the manual orchestration at this stage of the transformation. If your organization already has a PMO then these are the type of people you need to facilitate.

Can the PMO go away one day?  The only responsible answer I can give is, “When your organization is ready.”

One last caveat.  I’ve seen some organizations that are split, some parts need the PMO due to organizational and technical debt, and other parts have been built to be decoupled and on a continuous delivery cycle eliminating the need for manual orchestration.

The post Should the PMO go away? appeared first on LeadingAgile.

Categories: Blogs

The Business Analyst and the Product Owner

Leading Answers - Mike Griffiths - Mon, 01/09/2017 - 23:59
In my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of... Mike Griffiths
Categories: Blogs

Atlassian Spends $425 million for Trello

Scrum Expert - Mon, 01/09/2017 - 16:39
Atlassian has just announced it has entered into a definitive agreement to acquire Trello, the online project management service that gained more than 19 million registered users in just five years. The acquisition is valued at approximately $425 million, which is comprised of approximately $360 million in cash and the remainder in Atlassian restricted shares, restricted share units and options to acquire Atlassian shares. Through virtual ‘sticky notes’ and digital whiteboards for organization and prioritization of work, Trello’s easy-to-use software has proven especially popular with business teams, also due to its free version. Trello is poised to be a key product in the Atlassian portfolio, providing a new way for teams to organize and prioritize the often complex range of information and idea sharing that feeds into great teamwork. In addition to launching a new version of its existing Trello integration for HipChat, Atlassian will be launching Trello integrations for its other collaboration products, including JIRA Software, Confluence and Bitbucket. The integrations will be available in the Atlassian Marketplace.
Categories: Communities

Targetprocess v.3.10.8: Custom Request Types

TargetProcess - Edge of Chaos Blog - Mon, 01/09/2017 - 10:46

Custom Request Types

Custom Request types increase the number of scenarios that the Service Desk can be used for. For example, you could add "Project Request" if you're doing Portfolio Management, "IT request" for infrastructure guys, and much more. Alternatively, you can simplify Idea Management by removing all Request types except for "Idea".


Fixed Bugs
  • Requiring a comment for state transfers is now supported in Boards and Lists. If checked, users are requested to input a comment before moving an entity to the selected state.
  • Fixed: Non-admin user could change their team role without 'add/edit team' permissions
  • POP plugin won't create a requester if a Targetprocess User with the same email already exists
  • Fixed email notification duplicates in the case of reply-to comments where the same person is mentioned and addressed
  • REST api/v1: InboundAssignables, OutboundAssignables endpoints with CustomField collection included returned empty value
Categories: Companies

The Story of Tesla, by Elon Musk

Scrum Breakfast - Mon, 01/09/2017 - 10:00
They didn't know it at the time but they created the first Tesla Roadster by taking a working prototype and iterating on the design. By the time the Roadster was announced, they had replaced 96% of the original prototype. "It's amazing what we can do with small teams and tiny budgets." BTW this is part one, you'll want to stay for most of part two. Another video I had to watch to the end!

Categories: Blogs

Playing Whack-A-Mole With Risk

Tyner Blain - Scott Sehlhorst - Mon, 01/09/2017 - 05:44

Man playing whack-a-mole carnival game

Assumptions are interesting things – we all make them all the time, and we rarely acknowledge that we’re doing it.  When it comes to developing a product strategy – or even making decisions about how best to create a product, one of these assumptions is likely to be what causes us to fail.  We can, however, reduce the chance of that happening.

Being Wrong

What does it feel like to be wrong?  Watch about 25 seconds of this TED talk from Kathryn Schultz, starting at 4:09

Go back later and watch her entire talk – it is really worth it.  But stay with me for now.  All you need for this article is the 25 seconds, and the realization that you don’t know you are wrong until you know you’re wrong.

Hidden in Plain Sight

Assumptions are like being wrong.  But with an added degree of difficulty.  Not only do you not know you’re wrong – but you didn’t realize you were incorrectly asserting something, and then betting on it to be right.

Every strategy, every product idea, every design approach, and every planned implementation is built upon a pile of assumptions.  Those assumptions are there, if you just look at them.  But you have to look for them in order to see them.  They are hidden in plain sight.

The only question is if they are going to cause you any trouble.  You might not be wrong, in the assumptions that really matter.

Wouldn’t it be nice to know when you are wrong?  Before it’s too late?  Before it’s really expensive?  Before your window of opportunity closes?

Identifying Risky Assumptions

Laura Klein spoke at the Lean Startup Conference about identifying risky assumptions and her talk was published in Dec 2014.  Laura is also rapidly becoming on of my favorite gurus.  I just wish I’d become aware of her work sooner.

Laura identifies that every product has at least three different classes of assumptions.

  1. Problem Assumptions – we assume there is a market-viable problem worth solving.
  2. Solution Assumptions – we assume our approach to addressing the problem is the right one.
  3. Implementation Assumptions – we assume we can execute to make our solution a reality, such that it solves the problem and we succeed.

Hold onto this thought – I need to segue and dust off a tool I found five years ago, and some work I’ve done with clients over the last couple of years.  We’ll look at how to incorporate some of those ideas with the ones Laura shared.  And eventually, the whack-a-mole reference will make sense.

Hypotheses and Assumptions

With a client last year, I ran a workshop to elicit assumptions on our project.  We were working to develop what Harry Max calls the theory of our product.  Basically, we were working to develop the vision, the value propositions (for a two-sided market problem), the business model that would enable a credible market entry strategy given the company’s current situation, and a viable solution approach.  Essentially, product strategy and product ideation.

My assertion in that workshop was that assumptions and hypotheses, practically speaking, are risks.

assumptions are implicit risks. hypotheses are explicit risks

Product strategy and product design are a formulated plan of action, built upon a set of beliefs – assumptions and hypotheses.  The risk is that those beliefs are wrong.  And we don’t realize it.  Materially, the only difference between an assumption and a hypothesis is that the assumption is something no one has said out loud.  It represents an implicit risk.  Once you acknowledge the assumption, you can then treat it explicitly – and explicitly decide to do something about it or not. In the workshop I prompted the participants (senior executives, domain experts, product stakeholders and team members) to identify their assumptions and hypotheses.  I started by presenting several hypotheses and assumptions that had been part of conversations prior to the workshop. prompting assumptions - grayed out This helped elicit ideas from the group, but it wasn’t really enough.  What did get things moving was some prompts from Harry, such as the suggestion to complete the sentence “It will never work because..” or “The only way it will work is if…” sticky notes from elicitation workshop We were able to elicit and then organize (affinity mapping) the inputs into a collection of testable hypotheses. What To Do With a Pile of Hypotheses? Now, armed with a list of hypotheses, and limited time and resources to go test them all, we were faced with the challenge of determining which risk to address first.  Remember – hypotheses and assumptions are risks.  Risks of being wrong (and not knowing it).  Risks of product failure. I’ve historically used potential impact and likelihood of happening to manage risks.  I first learned to assign a score from 1 to 3 for likelihood of the risky thing happening, and a score from 1 to 3 of how bad would it be if it did happen.  Multiply the two together, and you get a score from 1 to 9 (1,2,3,4,6,9).  I learned this from PMO-trained people in the late 1990’s.  Maybe their thinking has evolved since then.  There are two problems with creating a score like this.
  1. Likelihood of occurrence and potential impact are treated as equally important factors.  An unlikely but major impact risk would be “as important” as a likely risk with minimal impact.  Each particular approach to risk management will value these differently.
  2. Combining the two pieces of information into a single piece of information is discarding useful information.  If I tell you one risk is a “3” and the other is a “4”, you cannot know which risk is more important to you.  The “4” is something that reasonably could happen, and would be “bad.”  Would that be more important than understanding the risk of an unlikely, but company-ending risk? Would it be more important than a very likely annoyance – one which may cause death by a thousand cuts for your company is large volumes of support costs absorb profits.
That’s why I’ve treated this as a two-dimensional space – visualizing a graph of likelihood vs impact. Laura proposed my now-favorite labels for this graph, relabeling my vertical axis.  I’m shamelessly stealing this from Laura.  It seemed fitting as Laura credits part of her presentation to Janice Frasier.  Maybe one of the ideas I’m adding to the mix will be stolen by the next person to add to our blog-post conga line. likelihood vs impact graph As a team, you can reach consensus around the relative placement of all of the risks.  We then began tracking against our top 10. top 10 risks mapped against impact and likelihood scales As Laura would say – you start with the “uppiest and rightiest.”  What you are doing is asking the question  – what risk is most likely to kill your product, damage your stock price, get your CEO fired, etc. There’s another dimension which makes treating risks this way difficult – uncertainty.  You don’t actually know that this risky think is likely to happen.  You’re incept-assuming as you make assumptions about your assumptions. The easiest way to think about this it acknowledge that your impact and likelihood “measurements” are not measurements – they are estimates.  They may be calibrated estimates, ala Hubbard’s How to Measure Anything or they may be guesses based on which way the wind is blowing.  Treat them as estimates, and then – plot them either as your “most likely” or your “worst case” point of view – that’s a stylistic call, I think. Removing Risks

man playing whack-a-mole game

The reason you test a hypothesis is to reduce a risk.  I think Laura used the phrase “to de-risk” the risk. To de-risk the risk, the first think you need to do is remove the uncertainty you have about how bad things could really possibly be.  You need to run an experiment.  In the example above, you would prefer to test hypothesis 7 first if you can – it is the uppiest and rightiest.  You would not be far wrong if you tested 4 or 8 first (assuming it is easier, faster, or cheaper to test one of those).  If you were to first test anything other than 4,8,7, you really should have a good reason. Once you run your experiment and determine that the risk is not a risk, go back and address the next-most-important risk.  This is a game of whack-a-mole.  You will never run out of testable risks.  You will only eventually reach a point where the economic value of delaying your product to keep testing risks no longer makes sense. Note that an experiment could result in multiple outcomes and next steps.  Here are a couple
  • This risk is not as impactful as we thought, we won’t address it with product changes, we will absorb those costs into our profitability model and revisit pricing to assure the business case still holds up.
  • This risk is every bit as likely as we were afraid.  Let’s determine a problem restatement (or solution design approach) where this risk no longer has  the impact or likelihood it did before.  As an example – a risk of users not adopting a product with an inelegant experience may justify rethinking the approach and investing to improve the user experience.

Trying to tackle all the ways you can respond to risks (and de-risked risks) would make this overly long article ridiculously long.

Validation Board

validation board

n 2012 I came across the hypothesis board from  At the time, it was free for use by consultants :)  I don’t believe it has gained widespread adoption.  At least people look at me funny when I mention it. Maybe now, more people will know about it. I personally never used it because something felt not-quite-helpful enough for me, for the problems I was helping my clients to solve.  I could never figure out why, however.  The board has many of the important components.  In hindsight, this is an indicator that the validation board is likely solving a problem I don’t have (as opposed to being a bad solution to a problem I do have). The validation board is structured more for early-startup customer-discovery work – with three categories of hypotheses to track – customer, problem, and solution
  • How big is the potential market?
  • How valuable is the problem we would solve?
  • Are we able to solve the problem for these people?
The tool was positioned as something to help you pivot as you discover that you have the wrong customers, or problems, or solutions. What I need is to know what hypothesis to test next.  I think that may be best done with a simple graph like the ones Laura and I use.  but use her labels. Whack Some Moles Instead of debating about implementation details, consider assessing the risks to your product.  Determine if those risks warrant making an investment to reduce them.  Form a measurable hypothesis and validate it. Then go after the next risk.  Until the remaining risks are no longer big enough for you to pursue.
Categories: Blogs

[2nd Part] Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

In my previous post I explained some of the foundemantals steps for implementing an Agile and Lean Portfolio Management. Want to know how actually strategy drives execution of company Big Initiatives, through Agile and Lean?! In my previous post I wrote why Agile/Lean Values and Principles are the most critical point to start with, also […]
Categories: Blogs

Clean Disruption

Scrum Breakfast - Sun, 01/08/2017 - 15:13
Why Energy & Transportation will be Obsolete by 2030 by Tony Seba. The horse was displaced by the automobile in just 13 years. Oil, Cars and the Power Grid are about to be transformed in a similar way. What other technologies will be displaced faster than you think, and why?

I don't usually have patience to watch a 45 minute video, but I had to watch this one to the end!
Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.