Back in 2007 I worked with Dr. Dan for a number of years. I don’t always agree with Dan … and in fact we’ve had long arguments about some of the smallest topics in Scrum. I remember a cold and wet road trip with him in his 1980′s Jag, travelling from Seattle down to Portland. We debated all the way there and all the way back!

However, I’ve always found that every time I talk with Dr. Dan I’ve learn something new, and our conversations have always been in good humour with lots of laughter. This conversation is no different … the conversation wanders through a variety of topics from Dr. Dan’s introduction to the Scrum community, his book and the new book that he’s writing.

Dr. Dan’s book is called Exploring Scrum: The Fundamentals.

About half way into the interview Dr. Dan starts talking about Cosmic Function Points. I almost sounds like a new age approach to Agile software development but he’s really talking about the complexity of the data flow between components in a system. It’s an interesting concept, although I think he could have chosen a better name!

Dan spend many years in the Military and this comes across in the interview as he frequent draws analogies with Military practice and life. I especially like this quote from the end of the interview were he talks about the how the Army scales and says:

… the pattern works. We know it works; it works in a complex domain called warfare and it’ll work in a very complex domain we call software. -Dr. Dan Rawsthorne

Here’s the interview:

Transcript

The post Large Scale Scrum and Cosmic function points with Dr. Dan Rawsthorne appeared first on Scrumology.com.

Mingle Team

Our recent "Best Card Wall" competition highlighted the varied ways in which the card wall is used for planning, estimation, visibility, tracking, decision making and reporting activities.

In this series, we’ll see how Mingle's card wall can help you create many different views displaying customizable information for various purposes, levels and roles.

Thumbnail: 

read more

As most of you are aware, on Wednesday, June 12, we experienced an unplanned outage between the hours of 10:56 a.m. CDT (GMT-6) and 1:32 p.m. CDT (GMT-6). It is always our goal to provide uninterrupted service, and we sincerely regret the incident. Our CTO, Stephen Franklin, and I want to assure you that the [...]

The post June 12 Service Interruption Update appeared first on Blog | LeanKit.

If you use the “component” field within Assembla’s Tickets Tool, this post is for you. The component field has been removed as a default ticket field. If your project used the component field, don’t worry, we have maintained this field within your project as a “custom field” that's still available on all tickets. New projects created will no longer have the component field by default, but if you miss it, you can easily create it as a custom field. We encourage new users try the recently released tags for tickets feature thats provides similar functionality with enhanced filtering options.

So how does this affect you?

The default "Active by Component" and "Closed by Component" filters are no longer available. If you or your team used these filters, you can easily bring them back by creating a custom filter, grouped by component:

• From the ticket list view, click on “Filter” in the upper left to expose the report builder.

• Set “Sorting and Grouping” to group by component and set to only show tickets that are open. This will create a report similar to the previous “Active by Component.”

• When you are done building the desired report, scroll to the bottom, name it, and save it. You can “Share with team” where all team members have access to this report in the “Team Filters” section of the filter dropdown.

Now that the component field is a custom field, instead of an Assembla default, you can edit the properties or remove it by going to your Ticket Tool > Settings subtab > Ticket Fields section.

Ticket Tool Tip:

Did you know you can change the default filters and views (Ticket List, Cardwall, and Planner) from the Settings tab of your Ticket Tool? This saves time by immediately placing team members on the most used filter and view when they login to your Assembla project.

Product Backlog Items are ordered into a sequence in the Product Backlog in such a way that the Product Owner is able to maximize the return on investment (ROI) in the team.  The very first PBI in the Product Backlog should be the one with the highest expected value considering the effort to build the PBI.  There are many ways to calculate this expected value including Return on Investment (ROI), Net Income After Taxes (NIAT), Net Present Value (NPV), etc.  The Scrum Team members should be free to ask why one PBI is prioritized higher than another, and the Product Owner should be able to give a reasonable answer. Since the entire Scrum Team is accountable for its work, it is in the best interest of all members of the team to use expected value, so that both the Scrum team and the customer will be committed to the work that is currently being worked on and the upcoming work in the future Sprints.  If we don’t order the PBIs by expected value, then the Product Owner is likely to prioritize them based on dates, feelings, urgency, or other less valuable methods.  These other prioritization methods will diminish the trust of the team in the Product Owner and may lead to morale problems.

Tuesday June 4th, Xebia organized the XebiCon event in Fort Voordorp in The Netherlands.  One of our visitors, Dirk Louwers, wrote a conference report which nicely summarizes the day. Dirk Louwers works as CTO for a company called Plot. XebiCon consisted of two keynotes and 15 sessions divided over five parallel tracks. Dirk Louwers reports on both keynotes and three of the parallel sessions.

You can read Dirk Louwer’s report at Plot Visits XebiCon

Thanks to Dirk Louwers for publishing this article!

Many larger enterprises leverage their IT development with outsourcing partners in India, China and other parts of the world, so the Scaled Agile Framework is routinely applied in widely geographically distributed organizations. (Heck, that’s probably one of the main reasons it exists.) In this case study, we describe one such example. Infogain Corporation (http://www.infogain.com/) is an India-based outsourcing service provider that adopted SAFe in multiple client programs to foster better alignment with client stakeholders and the development teams in order to accelerate reliable, synchronized, and high-value software delivery.

Several years ago I tried to discuss the need for Lean when Scrum was being used on projects with more than one team.  Ken Schwaber didn’t want to hear this and eventually threw me off the Scrum Development Yahoo discussions group.  I admit, I was talking outside the domain of what he wanted – the pretense was that Scrum wasn’t Lean and the Scrum Development group wasn’t the place to talk about...

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

What is "Scrumban"? The name seems to offer a simple answer - surely it's a mixture of Scrum and Kanban? So you think the rules of Scrum are a bit strict. You think Kanban doesn't offer enough guidance on things like roles and when planning and retrospectives should take place? Why not just mix the two and things are bound to be better!

The only snag with this is that Scrum and Kanban already have definitions which are not really compatible with this mixture idea. And Scrumban, at least in the original usage of the term, was coined with a different meaning than mixing the two methods (see Scrumban, Corey Ladas 2009).

The definition of what is and isn’t Scrum is well understood, thanks to the concise publication of its “rules” in the Scrum Guide. Scrum is a process framework – a set of guidelines and constraints within which your team can define and improve the process you use for developing products. It’s not a process as such - it is silent on many of the aspects a process needs (it says you need a “Definition of Done” for example, but not what it should be). However it is a framework that is very specific about some aspects of the process, such as when planning meetings take place and how long they should last.

Scrum is often contrasted with Kanban, also a framework, but more accurately described as an improvement framework; that is the approach for assessing and improving your process. Kanban has fewer constraints or rules than Scrum, allowing a wide range of processes from those based on Scrum itself to many variants – agile and less agile – which can be the process's starting point . As +David Anderson explains, "A Kanban system is overlaid on an existing process." Provided you can look at your work as a flow of items - usually this is simply a case of changing the way you look at your work - you can use Kanban to assess and improve your process.

As yet there is not the simple definition booklet that defines what is and is not Kanban, so the best starting point is the “Blue Book”, Kanban (Anderson, 2007), plus the summaries - published informally since that time - of the foundational principles and core practices. Because I like short definitions, I've summarised these as "how to adopt Kanban":

1. See work as flow (Lean Flow Paradigm)
2. Start from here and improve (Foundational Principles)
3. Make work and policies explicit;
   Make validated improvements (Core Practices)

If you are doing this, you are doing Kanban, even if your policy for work in progress (usually cited as a key difference between Scrum and Kanban), is to limit work in a Sprint to that which the team believes it can complete (the policy that Scrum applies)... or if you decide not to limit work in progress at all.

In fact there is nothing in Scrum that is incompatible with adopting Kanban as well. Nothing that is except the “rule” that the rules can’t change. If you can validate that it would be an improvement to do planning more or less frequently, or to decouple the frenquency at which you do retrospectives from the frequency at which you do reviews, Kanban would say you should make that change. Scrum might say okay make the change too, but if you do so you are no longer doing Scrum.

So this is the key to what Scrumban is. Scrumban is a process being improved using Kanban, which probably is no longer strictly Scrum. Some part of the strict Scrum framework has been modified (or maybe was never tried) because it is believed the change is more appropriate, brings more benefits or incurs less cost than pure Scrum. Such processes used to be referred to, somewhat derogatorily as “Scrumbut”. Scrumban is the more acceptable, less pejorative alternative... and it's also more positive because it implies you're using Kanban.

In his book on Scrumban, Corey Ladas describes a possible trajectory for a process that starts off as Scrum and changes as Kanban improvements are applied. This is what he meant by “Scrumban”. At the end of the story the process has very little similarity to Scrum and few people would even describe it as “Scrumban”. It is simply a flow-based process, as near as possible to single piece flow, with a typical Kanban improvement process around it. Is this process still Scrumban? At the point when the similarities to Scrum have disappeared, I’d suggest the label is not helpful. Many have concluded the label itself is not helpful anywhere since it causes the kind of confusion that is visible in statements like "I prefer Scumban to Kanban" or "Kanban is a better process than Scrum". Look at the definition of these terms and it’s clear such statements are not really meaningful.

I think though that a commonly accepted definition of Scrumban would be useful, at least to reduce the confusion in discussions around this topic. So here’s my attempt:

“Scrumban is a Scrum or Scrum-like process which is being improved with Kanban.”

This definition implies that if you are doing Scrumban you are using Kanban! Maybe that will be difficult to accept for some people, particularly if they believe their approach is "better than Kanban". Maybe a Scrumban community will emerge and wish to define distinctive practices from Kanban, just as most Scrumban processes differ from Scrum in some (albeit different) ways. In the meantime I’ll continue to use the term Scrumban - guilty secret: yes I do use the word! And when I do, that’s what I mean by it.

Postscript:
You can't do Kanban in a vacuum. You need a starting point. If your starting process is based on Scrum or is Scrum-like, then according to this definition it is Scrumban. If the starting point was Prince II or XP or DSDM should you call it Princeban, XPban or DSDMban?!

Andres and I recently found ourselves wanting to delete a remote branch which had the same name as a tag and therefore the normal way of doing that wasn’t worked out as well as we’d hoped.

I created a dummy repository to recreate the state we’d got ourselves into:

$ echo "mark" > README
$ git commit -am "readme"
$ echo "for the branch" >> README 
$ git commit -am "for the branch"
 
$ git checkout -b same
Switched to a new branch 'same'
 
$ git push origin same
Counting objects: 5, done.
Writing objects: 100% (3/3), 263 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://git@bitbucket.org/markhneedham/branch-tag-test.git
 * [new branch]      same -> same
 
$ git checkout master
$ echo "for the tag" >> README
$ git commit -am "for the tag"
$ git tag same
$ git push origin refs/tags/same
Counting objects: 5, done.
Writing objects: 100% (3/3), 266 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://git@bitbucket.org/markhneedham/branch-tag-test.git
 * [new tag]         same -> same

We wanted to delete the remote ‘same’ branch and the following command would work if we hadn’t created a tag with the same name. Instead it throws an error:

$ git push origin :same
error: dst refspec same matches more than one.
error: failed to push some refs to 'ssh://git@bitbucket.org/markhneedham/branch-tag-test.git'

We learnt that what we needed to do was refer to the full path for the branch when trying to delete it remotely:

$ git push origin :refs/heads/same
To ssh://git@bitbucket.org/markhneedham/branch-tag-test.git
 - [deleted]         same

To delete the tag we could do the same thing:

$ git push origin :refs/tags/same
remote: warning: Deleting a non-existent ref.
To ssh://git@bitbucket.org/markhneedham/branch-tag-test.git
 - [deleted]         same

Of course the tag and branch still exist locally:

$ ls -alh .git/refs/heads/
total 16
drwxr-xr-x  4 markhneedham  wheel   136B 13 Jun 23:09 .
drwxr-xr-x  5 markhneedham  wheel   170B 13 Jun 22:39 ..
-rw-r--r--  1 markhneedham  wheel    41B 13 Jun 23:08 master
-rw-r--r--  1 markhneedham  wheel    41B 13 Jun 23:08 same
 
$ ls -alh .git/refs/tags/
total 8
drwxr-xr-x  3 markhneedham  wheel   102B 13 Jun 23:08 .
drwxr-xr-x  5 markhneedham  wheel   170B 13 Jun 22:39 ..
-rw-r--r--  1 markhneedham  wheel    41B 13 Jun 23:08 same

So we got rid of them as well:

$ git checkout master
Switched to branch 'master'
$ git branch -d same
Deleted branch same (was 08ad88c).
$ git tag -d same
Deleted tag 'same' (was 1187891)

And now they are gone:

$ ls -alh .git/refs/heads/
total 8
drwxr-xr-x  3 markhneedham  wheel   102B 13 Jun 23:16 .
drwxr-xr-x  5 markhneedham  wheel   170B 13 Jun 22:39 ..
-rw-r--r--  1 markhneedham  wheel    41B 13 Jun 23:08 master
$ ls -alh .git/refs/tags/
total 0
drwxr-xr-x  2 markhneedham  wheel    68B 13 Jun 23:16 .
drwxr-xr-x  5 markhneedham  wheel   170B 13 Jun 22:39 ..

Out of interest we’d ended up with this situation by mistake rather than by design but it was still fun to do a little bit of git digging to figure out how to solve the problem we’d created for ourselves.

These days most dev organizations can configure themselves around agile thinking. That is only half the battle. Unless the rest of the company – be it sales, marketing, finance – also adopt the agile mindset, you risk launching misunderstood products eg. what seems like MVP to the development team, seems like buggy features to the marketing team. At its core, agile teaches us that a clear vision of the end product is not necessary. But unless the sales team is bought into dev’s vision of “get it wrong before you get ...

When people think about continuous delivery, they think about speed.  They want faster delivery of high priority requests, from idea to release.  However, we found that we use the capacity that we get from continuous delivery to reduce stress, rather than increase speed.

I think that the stress reduction comes from three sources:

1) Things get fixed faster.  Problems don’t have time to build up.  If you have to wait many weeks to get a fix for a problem, stress builds up in that time.  Everyone affected by the problem is working around it and asking questions and applying pressure.  It feels better to just deploy small fixes and improvements can get deployed quickly.

2) Complicated work can take longer.  Everything gets finished on its own schedule, so you can take a long time to finish and test something complicated.  You don’t have the added stress of trying to fit it into a particular release.  You can use the extra time to improve quality and confidence.

3) Less work.  You can remove some batch planning work, including iteration planning, release planning, and status reporting.

Jumping out of a perfectly good airplane, while in flight, without a parachute is generally not recommended. Strangely, it’s exactly what happens in a lot of corporate lean/agile transformations. People jump enthusiastically, enjoying the rush of sudden speed and the exhilaration of getting things done as a team, only to discover organizational gravity when they hit rock bottom.

If only we knew how to fly. In his acclaimed survival manual “The Hitchhiker’s Guide To The Galaxy,” Douglas Adams points out that there is an art, or rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss.

To be able to do that, you need power. And for that, you need to know a little bit about how to get it. You need to know about politics.

The political economy of lean transformations

Talking about the political economy of lean/agile transformations always brings a smile to my face. As a political economist turned computer programmer, turned delivery manager, turned project manager, and ultimately turned management consultant, I can talk for hours about this and not get bored.

Don’t worry though, I’ll give you the short summary. The very short summary in fact: All politics is a struggle for power. The political economy of lean/agile transformations then, looks at the effects of the redistribution of power in an organization.

Now, there’s something special about power. To speak with Rosabeth Moss Kanter: “Power is a dirty word. It is easier to talk about money and much easier to talk about sex than it is to talk about power. People who have it deny it; People who want it do not want to appear to hunger for it; And people who engage in its machinations do so secretly.”

Let’s open up about power for a bit. And while we’re at it, let’s lighten up about power as well.

And let’s begin with the end in mind: To learn what you need to know about power to become a more effective change agent, you don’t have to read Machiavelli. You just have to read this book: “Power, Why Some People Have It – And Others Don’t,” by Jeffrey Pfeffer. In that book, the Stanford Professor of Organizational Behavior provides ten tips to help you wield power like a Jedi with a light saber:

• Mete out resources.
• Shape behavior through rewards and punishments.
• Advance on multiple fronts.
• Make the first move.
• Co-opt antagonists.
• Remove rivals–nicely, if possible.
• Don’t draw unnecessary fire.
• Use the personal touch.
• Make important relationships work–no matter what.
• Make the vision compelling.

Why should you learn about power? You should learn about power for three reasons:

• First, power is a tool. A sharpened saw in stead of a dull one. By knowing about power, you can help organizations change faster, with less risk of organizational gravity wreaking havoc on your hard work. All tools can be used for evil as well as good. It’s the same with power. Most of us that “don’t like to play games” are just afraid we’ll lose. That’s not principled. That’s chickening out. Wielding power purposefully allows you to be more effective as a change agent. Don’t fight the power, grab it!
• The second reason you should learn about power is that your opponents have learnt how to wield it to create and protect the status quo. Rest assured that as you enter an organization, it will be structured in such as way as to conserve the status quo. It’s a natural state for organizations. Well, sort of. In reality, all systems are in a state of continuous flux. Which is why all the politicking occurs. It is needed to maintain the status quo. It’s also needed to topple it.
• The third reason you should learn about power is because of what happens to power in a successful corporate lean/agile transformation. Transforming organizations from a traditional to an lean/agile structure entails a democratization of power in the organization. From management to teams, from IT to business, from top to bottom. Power gets redistributed from the elite to the masses. It’s a radical democratization of decision making power. Such redistributions are generally met with a combination of enthousiasm and resistance. Both are understandable.

But there is another reason companies are remarkably resistant to change. This has to do with organizational gravity.

The concept of organizational gravity

The concept of organizational gravity comes from Mike Cohn. In his book “Succeeding With Agile,” Cohn describes the tendency of an organization to slowly, but surely, veer back to it’s original state. Old habits die hard.

Organizations are structured to maintain the status quo. To escape that, you have to exert a lot of power. The larger the organization, the more power you’ll have to exert. If you don’t exert enough power, whatever you launched will either come crashing down or at best achieve orbit.

Some real life examples

Let’s talk about some real life examples for a minute.

Way back when I was still a Project Manager struggling to convince management that an agile way of working would yield better results, I got called into the office of the head of Project Management. He showed me a letter from one of our most important clients. The letter said we would loose the contract if we did not improve within three months. “That’s your assignment,” the head of Project Management told me, “do whatever it takes to make it right so we don’t loose the client.” And I did. What it took, was some remedial team building and the introduction of an agile way of working. Within six months, the client sent us another letter. This time, it was a signed reference for marketing purposes. A dramatic reversal of customer satisfaction! All thanks to adopting an agile way of working. They kept improving on that way of working after I left and today have a rock solid reputation for delivering high quality software to millions of users. This then, is an example of an organization truly overcoming organizational gravity.

More recently, I consulted with a company that wanted to deliver faster, more relevant software to production with higher quality at lower cost. They’d done a lean transformation already, and asked us to do an agile one as well. So we did. And it was a success! We helped the client create multiple agile teams simultaneously working on the same technology stack and worked with management to introduce a governance structure feeding those teams with a single corporate backlog. And then, the financial crisis hit home. The company had to cut costs fast. So they did the now obvious thing: They asked their agile teams for help. And the teams told management to fire half of them. So they did! How about that? You ask the turkey what to have for dinner for Christmas and his advice is to have turkey! That was the level of understanding the teams had gained from adopting an agile way of working. But, there’s a sad end to this story. The shift from continuous improvement to cost-cutting, that is from Eastern lean to Western lean, destroyed employee loyalty to the company. The first to go off to greener pastures were the managers and team members instrumental in the initial change. Then, organizational gravity hit hard. Last I heard, the teams are being told what to do by management and have stopped thinking for themselves. Apparently, overcoming organizational gravity is not enough, you have to keep at it to avoid falling back down.

Overcoming organizational gravity

So, how do you overcome organizational gravity? And how can you make sure you keep at it to avoid falling back down?

Speed is essential. The faster you go, the faster you’ll show results. The more results you show, the easier it is to maintain momentum and push for a real and lasting change. Also, speed sharpens your focus and facilitates flow. It hightens your senses and prevents you from cruising along without paying close attention to what you’re doing. Just like driving a supercar on a racetrack.

Trouble is, you’re not actually on a racetrack in a corporate lean/agile transformation. For starters, there usually a lot more cars on the road. And they’re not all supercars. They drive at different speeds. Worse, they follow different rules. Worse still, they might not be going in the same direction.

So a corporate lean/agile transformation is more like driving a supercar through heavy cross-town traffic. If you want to do that at speed, it’s hard to keep going without accidents. It’s impossible to do that without breaking the rules.

Breaking the rules is essential. Or rather, using and bending the rules so they work in your favor. To cut through cross-town traffic in a supercar at speed, all you need is flashing lights, a siren, and a badge. In a corporate setting, that’s a sense of urgency, vocal executive support, and power. However, if you’re using and bending the rules in your favor, you’d better have a good reason and a great sense of direction. If not, you’ll lose popular support really quickly.

Navigation is essential. If you don’t know where you’re going, any road’ll take you there. So you have to know where you’re going. Or rather, where you currently want to go. And then get everyone to go along. A great and proven way to do just that on all levels in a corporate setting is applying Toyota Kata:

• What is the target condition?
• What is the actual condition?
• What obstacles are preventing you from reaching the target condition? Which one are you addressing now?
• What’s your next step?
• When can we go and see what we have learned from taking the next step?

What we call lean/agile today, resulted in large part from answering those five questions consistently over time. As Mike Rother points out in his book “Toyota Kata,” the roots of Toyota’s success lie not in its organizational structures, but in developing capability and habits in its people. The competitive advantage of an organization lies not so much in the solutions themselves, but in the ability to understand conditions and create fitting smart solutions.

This points to an important, and in my opinion sorely missed, addition to the Agile Manifesto:

Experimentation over implementation.

Do something. See if it works. If it does, do more of that. If it doesn’t, do something else. As opposed to think of something. Talk about it. Talk about it some more. Then talk about something else.

If you don’t go fast, break the rules, and navigate like a pro, you’re likely to go SPLAT! Avoiding a Surprisingly Painful Lean/Agile Transformation (SPLAT), is hard work.

It’s hard work to keep up the pace. In a truly lean/agile organization, you’re not just sprinting, you’re doing back-to-back sprints without stopping. It’s more like a marathon. Actually it’s more like an ultra. To be able to do that, you must want it badly. And you must train. A lot.

It’s hard to break the rules. Sometimes, this may get you fired. Like in the story Brian Marick likes to tell about a certain Scrum Master:

• An agile team was made to work in cubicles, like the rest of the company.
• Agile methods aside, cubicles are the “single worst arrangement of humans and objects in space for the purpose of developing software.”
• The team proposed changing their workspace to an open one.
• Furniture Police turned them down.
• In response, the Scrum Master went to the office over the weekend. She disassembled the cubicles and changed the office layout to an open one. On Monday, she declared to the Furniture Police that “If the cubicles come back, you will have to fire me.”
• They gave in.

But they could have just as well taken her up on her offer and fired her.

Hard work, hard work, hard work. Are there really no shortcuts? Well, no, not really. But you can speed things up a bit. Quite a bit in fact. Let’s have a look at some of these “wormholes.”

Wormholes to the rescue

A wormhole, or Einstein-Rosen bridge, is a shortcut through spacetime, much like a tunnel with two ends each in separate points in spacetime.

Start your lean/agile transformation small, but make sure to select a really important project. Preferably one with lots of risk and high pressure. This will allow you to start fracking the organization releasing the hidden energy reserves encased within.

Propose a ship-it day to show everyone the power of self-organization. Ship-it days are a fun way to foster creativity, allow people to scratch itches and get radical. They’re also a wake-up call to management showing them what happens if they stop holding people back.

No one in their right minds should be against the disciplined application of common sense. And that’s exactly what lean/agile is. In other words: Just do it. So if you can’t get anyone to approve your lean/agile transformation effort, remember it’s more blessed to ask forgiveness than permission. Get going, kickstart a never-ending cycle of continuous improvement, and merrily deal with whatever impediments you encounter to getting things done. Results don’t lie!

So, now for constructing your parachute on they way down to overcome organizational gravity. You jump in without a parachute. How do you avoid hitting rock bottom? I have seven tips for you to help you do that.

7 powertips for smarties

1. Be honest with yourself. See things as they are, not as you want them to be. Acknowledge your feelings, then use the scientific method to check their validity.
2. Use social network analysis to map the distribution of power in an organization. Visualizing the flow of power makes it easy to tap into it.
3. Use heat maps to identify the points of maximum leverage in an organization. Visualizing the distribution of power makes it easy to know where to start drilling for oil.
4. Create a power matrix to determine who to influence.
5. Show genuine interest in everyone you meet. You never know where they’ll end up later. Make eye contact, let them talk first, ask open-ended questions, listen.
6. Tap into the awesome power of the secretary or personal assistant. Get to know them. Treat them as you would their bosses.
7. If all else fails: Run!

Summary

Do your cause and yourself a favor, and learn about power. Be mindful of organizational gravity and use any means possible to overcome it, be it the smart use of power, plain-old hard work, or a shortcut. If you can’t beat them, or join ‘em and then beat them from within, run! Apply for a job at Semco, Google, or Toyota, to name just a few truly lean companies. Or start your own. Don’t settle for less! You deserve to work at an awesome company!

Companies are springing up with new thinking about how to structure and lead their organizations. I can think of Spotify, Valve and HubStop just to name a few and I’m sure there are plenty more out there. Every time I hear stories about these companies I am encouraged about what the future holds.

I feel a whole new way of approaching corporate structure, culture, collaboration and leadership is on the horizon. Many existing companies are taking great strides in changing their workplace to be more competitive and responsive…and dare we say, more human. They realize they must change or become obsolete.

For now however, the majority of people still work in companies stuck in the 20th century. If this includes you, bringing about structural, systemic, and foundational change will need a movement…and it will require boldness.

If you haven’t seen this video from Steve Denning from the StoosConnect event early this year it’s worth the 12 minutes. Starting at  7 minute mark he begins to speak passionately of the boldness we will need to see meaningful change happen.

Change is coming…

Be an instigator. Know what you value. Form a movement. Be passionate. Speak up. Be bold.

Find out more about the Stoos network here.
Follow Steve Denning on Twitter and read his blog on Forbes here.

 

The post The Required Boldness appeared first on Illustrated Agile.

This blogpost completes the model that I use to build up a mental image of a new crisis situation when I encounter one. I use it to structure and prioritize the thousands of pieces of new information that I need to process in order to get a good picture of what I’m dealing with. In fact it is a tool to get a fast and useful insight in the current crisis situation that will help me to consolidate all the different inputs into a combined and useful image of what’s going on. This image helps me to communicate with the stakeholders and to define the actions needed.

In my previous post the fundamentals of the model have been explained.
In this post the rest of the mental image usage is described.

figure: Burms temple

Remember the essence of the first blogpost:
A strong temple is built upon solid ground and a strong foundation; likewise a successful project is built upon engaged project members and clear responsibility.
When you want to assess a project, start with investigating engagement and responsibility. To do this, look at two things

• Are ‘change’ and ‘structure’ well balanced? So people have the opportunity to express their engagement.
• Is leadership and responsibility effectively implemented? So people operate in their strength and feel free to do what seems right?

Use the questions above to assess the fundamentals of a solution to any crisis.

Haha! Fundamentals are great, but not everything; So let’s move on!

PART III: THE TEMPLE FLOOR – A working value chain
Have you ever been in a real temple? The first thing that strikes you is the awesomeness of the beautiful floor. It’s that awesome floor that takes your breath away and makes you fall in love with this ancient piece of art The beauty of a successful project lies in the elegant effectiveness of a working valuechain, in two dimensions: the functional product dimension and the dimension of virtual ownership.

Looking at a value chain from a Functional point of view means, you have to get the minimal product working end-2-end. Once this is done, things can only get better.
Creating your mental picture of this area can take some effort. Domain knowledge is helpful, so talk to people who have it and look at the project history together. The product owner is a good place to start. Have a look at the storymap and if there is none, make one. You could also draw out end-2-end user interaction scenarios with the product owner. Start with the “happy flow” and once finished look at the features in it already built and what has to be added. Find out what’s holding the project back from completing an end-2-end value chain.
Example questions that can give you a head start:

• Can you explain to me what the minimal end-2-end functionality looks like?
• What’s the value of this functionality for the customer?
• What is needed to complete the first end-2-end functionality set?

Ownership wise, you have to take charge of the valuechain and what happens to it during the course of the project. If your program runs on shared environments, like sharing test or acceptance environments with other projects, find out what is the priority for your program. From there on implement some form of flight control mechanism. On shared environments the case is often that operations is expecting the supplying party to coordinate, and the supplying party is expecting the operations to coordinate. Result is a big mess you need to clean up.
To get an image of what’s going on, talk to Operations. See how often ops has issues when deploying and were they originate from. Of course it goes without saying that this point in your model gets more important and complex the more third party vendors are in acting in your value chain.
Questions I like to use to get my head around this part of the model:

• Who’s managing the timeslots and priorities on the different environments?
• How long does it take to execute a deployment? What kind of recurring issues occur?
• Which colleagues operate right before and right after you in the value chain?
• What’s to be considered the starting point of the value chain? What the end?

PART IV: Four majestic pillars that support the roof
There are four pillars that support the roof of our temple:

1. Create a single managed backlog:

It is imperative to have a single managed backlog. Derailed projects often show a myriad of specs and priorities across the entire program and strange constructs to manage these. Get the whole thing back to a single product owner and concrete priorities. Work out the backlog in rapid design workshops for at least the next release and estimate this with the entire team. To find out if productowners are aligned and focused, check if there is a single backlog or storymap in place together with a sort of chief product owner. Also check if the chief has a clear vision on the product (especially the bare minimal viable product) and the mandate to make decisions accordingly. A good second indicator is to see whether or not productowners are discussing central release goals instead of their own. How often do they jointly check if these central goals are going to be met? Even when there is a clear central backlog and goals, productowners could still work separately in practice mainly cleaning their own alleys.

2. Know your velocity:

In multi-team programs, it’s often hard to work with velocity across teams if you want to relate this to a centralized release- and/or product backlog. But in a program under pressure, it is imperative that you obtain this information to see what scope you will be able to finish given the circumstances and current delivery speeds. To check what’s happening based on velocity ask how teams do their estimation and who estimates what with regards to the final product. Next to this you can ask what reference point is being used and if this is the same for all teams. In the latter case, you usually see. You may need to adjust- and act on a number of things to make any sense of a common velocity, depending on the answer to the above questions.

3. Work end-2-end:

Planning wise you do not want any loose ends to be lying around. This is a great project risk. Velocity in relation to planning-information is only worth anything, when based on end-2-end results from the teams. So from requirement to production (ready) products. To check if the teams and the program as a whole is working end-2-end each sprint, look at program planning phases and talk to program and project managers. They might reveal that they want to do other test types after “development” work is “done”… My rule of thumb is the thinner the definition of done, the more risk is shifted to the end of the program, the harder it will be to mitigate this risk and tame the crisis.

4. Start continuous improvement on the program level in a PTC (Program Transition Community).

I am sure you have all heard of enterprise transition communities or ETC’s. Just like with an agile adoption, taming a project crisis is also not a one-time effort, but a continuous one. Solving all problems in just one go is an illusion. In derailed programs, continuous improvement on program level is often non-existing, and you can’t rely on the self-improvement of individual delivery teams alone. Simple look-ups can improve your mental image. See if there is a program level standup and if issues and impediments are made explicit. See if there is some record available of improvements etc. To see indications of the base to start improving on this level, look at the solve time for impediments not solved within the teams.

PART V: THE ROOF – Prioritized goals and the eternal bliss of: transparent, reliable program results
The pillars hold the roof. The main part of the temple, pointing towards the eternal bliss of transparent, reliable program results. The roof therefor represents the priority in program goals. In many programs in crisis we see, there are multiple program goals trying to be completed at the same time. The goals set by the steering committee have to be streamlined by prioritization. Just like the temple roof is pointy, everything done in the program at any given time should lead to the top priority goal. One goal at a time will keep the focus in the program optimal and guarantee the quickest results. People can still have their own sub-goals, but they should at all time have a direct contribution to the central goal with the highest priority. To get a view on this area, ask the same question to various people in different layers of the program hierarchy; what is our main priority/ goal right now? If your getting different answers there might be a problem (try to ask why to see if the answers lead the same destination), if people are unable to answer, you also have a problem. Also look if you see the goals being properly communicated and repeated. In group sessions, in written meeting minutes and most importantly in peoples workspace.

Conclusion
The first important step to resolve a crisis is to understand its context and situations. Easily said, but not always a simple thing to do. In complex situations, a model that offers a structure for prioritizing information and building up a mental image is of great help. Burms temple is such a model.

Next steps
The next step is to determine what actions need to be done to mitigate the current situation you have modeled using Burms temple. From here you and your client can share and form this common vision into an actionable plan, which will raise you from crisis-mode towards transparent, reliable program results……..

PS thanks again Geert!

Perforce Software has announced Perforce Swarm, a powerful code collaboration and peer review platform that enables development teams to work together better and faster, improving both the quality of their software and the speed of their delivery. Using Swarm, distributed development teams can i ...

Many of us use agile techniques and principles in our work lives. But how would you apply it to your own business? This post is about how we at Growing Agile keep everything we do visual and prioritised.

Planning & Structure
We split our days into 4 slots of 1.5hrs with 30 min breaks between and an hour for lunch. Then we have 5 areas we need to focus on. These evolved over time, but have been been the same for around 6 months now. These are the categories that are important to our business – so they would be different for everyone.

• Sales – this is building relationships, meeting new clients, existing clients, coffee’s with ScrumMasters, events etc.
• Learning – this is our own learning time. Working on our goal for the month, reading, courses, our coaching etc.
• Recurring – this includes our newsletter, admin, blog writing, planning, retrospectives – basically anything that happens regularly.
• Paid Work – this is training, coaching and preparation for those.
• Other – this is for things that are ad-hoc, like flights, public holidays etc.

We decide on a percentage split between the above categories that makes sense for us. We then allocate slots every two weeks according to these percentages. We have 4 slots a day, so a total of 20 slot a week. So for example: If 50% of our time is on paid work, then we allocate 10 slots to this every week.

Every 2 weeks we have a planning slot, where we plan our time for the next 4 weeks. The next 2 weeks are usually in detail and the following 2 weeks have more free time. This allows us to see what’s coming up and schedule client meetings. It also allows us not to over commit. We also try group our time, so that we have in-office and out-of-office days. The red circles are for out-of-office days.

Our plan goes into our google calendar and up on the wall in front of us using stickies. We adjust it as we need, but the big win here is that instead of cancelling a slot, we shift it somewhere else. This helps us ensure we are allocating our time to our agreed priorities.

Every 4 weeks we have a retrospective. We always use our past plan and adapt to make it work for us. It has changed ALOT over the last 18 months – I am pleased to say that it brings calm, happiness and structure to our lives

Depending on what slot we are in we have different ways to prioritise the work we do.

Admin Board
As mentioned we have an admin slot. We only plan this after a trip away. Usually we pick up admin tasks in our 30 min breaks or during lunch. After a trip, we find that we have more admin, because we are not doing it in our breaks, hence the slot allocation. All our admin tasks are small, around 5 – 10 minutes. We have a board on the wall with 4 headings: OneDay, ThisMonth, ThisWeek, Today. As we think of an admin task, we write it on a small post it and stick it up on the board in the appropriate column. The rule is: If it doesn’t have to be done today, then it shifts to ThisWeek etc.

The good thing about this board is we don’t feel like we’re going to forget something. We don’t need to do the action when we remember and get distracted, we just write it down and move on. Also it gives us a place to put those random “I just has an awesome idea! We MUST do it!” thoughts. And then in a few weeks, when we’re less attached to that great idea, we can admit it wasn’t that great and just get rid of the sticky Once a month we clean the board and get rid of everything we are ready to admit will just never happen.

Website Board
As a small startup its up to us to keep our website looking good and working well. We have many ideas and improvements and things we want to do. On our wall we have a quadrant with axes for Effort (low to high) and Value (low to high). All ideas go onto stickies and are placed on the quadrant relative to others with how much effort they will be vs their end value to us.
When we have a website slot, we first pull tasks from the low effort, high value quadrant, then from the high effort, high value etc. This helps us prioritise the highest ROI items first. It also gives us a place to keep all the ideas we have for our website.

Book Boards
For those of you who don’t know – we are about half way through writing a book. We manage this using a standard Kanban board. When we have a book slot – we pull from the board until the slot is up. We are also working on the South African version of Who Is Agile? Similarly this is visualised with a kanban board.

Idea Board
Occasionally we have big brainstorming sessions I LOVE them! We get to think wacky and crazy. Similarly to the Website board these go onto an Idea quadrant with Effort and Value axes. Once in a while we will feel inspired enough to turn an idea into our retro goal for the month. We will take the idea, and figure out how we will work on that idea.

Retrospective
We have a retrospective once a month. There are 2 of us and our retros are 90 minutes long. If we try to do this in a shorter period – we find that we are not digging deep enough to make great improvements. Our retros are planned and time-boxed. We go through all 5 stages (as per Agile Retrospectives). We change the activities every time and as there are only 2 of us, we both facilitate and take part. Each retrospective results in 1 goal for the following month, and it gets goal slots in our 4 week plan. Our goal is run as an experiment with outcomes, or assumptions we want to prove.

We also have a blog post ideas board and a sales board. As you can imagine – our boards take up ALOT of wall space. In fact all the walls in our office are used. The cool thing about this is at a glance – we can tell you just about anything about our business. It helps us stay focus and working on the most important thing right now.

Hope this gives you some insight into using visual stimuli in your office environment One interesting insight about our boards is that they track what we need to do, rather than what we have done. As soon as work is done the sticky goes in the bin. This is primarily because we don’t really care how much we do, we care that important stuff gets done, and that we spend our time in the most effective way possible. If this post inspires you to try a new type of board, let us know in the comments.

Scrum Teams work on one product at a time.  The Product Backlog represents all of the work that needs to be done on that single product.  The complete list of Product Backlog Items represents the goal of delivering all of the presently known features of a product.  Multiple teams working on a single product, therefore, work from a single, shared Product Backlog.  Working on Product Backlog Items from multiple Products causes the team to task switch into a different business domain and possibly into a different technical domain.  Task switching creates wasted mental effort and therefore causes a team to be less effective than they could otherwise be.  Having a single product to work on creates focus in both the business and technical domains.

Roy van de Water, Derek Neighbors and Clayton Lengel-Zigich discuss:

• Does money work?
• What if developers don’t realize they need to grow?
• Should developers choose their own path to grow?