In a similar vein to my previous post Project Managers Bridge to Agility I have recently stumbled across another nice article – this one from Pete Deemer at www.scrumtraininginstitute.com.

These things always ring so true – yet in practice it’s so hard for a company to do let go and trust in their team’s ability, especially when under pressure.
You really need to have all players sold on the belief that agile development does work.

As Jeff Sutherland mentioned in a seminar of his I went to last night, these things are so simple, but not necessarily easy.

Excerpt from MANAGER 2.0: THE ROLE OF THE MANAGER IN SCRUM below:

The traditional role of the manager in the corporate world is based on a model known as “command and control”. Here, the job of the manager is to identify what needs to be done, to issue detailed instructions to the employee, and then to ensure the employee completes the work according to the instructions. The role of the employee in this model is simply to follow the directions as given, trusting the judgment and wisdom of the manager to ensure that the right work is being done in the right way.

In complex, dynamic environments such as software development, this approach tends to break down. First, it is difficult and time-­-consuming for a manager to understand every requirement in full detail and issue precise instructions to guide the work of every employee. Within a software development Team, the work is highly interconnected, with intricate dependencies, and frequent change and surprise. To expect a single manager to do all the basic thinking for his or her team is unrealistic, and it often constrains the team’s productivity to the manager’s ability to give instructions. In addition, this approach tends to be demoralizing for employees; their role is simply that of “order follower”, and they often feel little sense of ownership of their work. Accountability is limited to answering the simple question, “did I complete the orders I was given?” If the answer is “yes”, the job has been done – regardless of whether the right thing was built, built well, or built to satisfy the business goals of the customer.

Scrum is based on a different approach: The Self-­-Organizing Team.

The Galaxy Team had been doing Scrum for several months, and the Team was
well on its way to being truly self-organizing. Their motivation was high, they were
focused, and after a few Sprints of under-delivery, they were now showing a
pattern of making reasonable commitments and delivering them 100% each
Sprint. Morale was high, and there was a real sense of “flow” in the work they
were doing. The engineering manager Francis had come a long way – once a
habitual micromanager, he was now acting like much more of a mentor and coach
for the Team. Unfortunately, though, in the eighth Sprint, the Team encountered
some unexpected difficulties, and about halfway through the Sprint, they were
significantly behind in their progress. The VP of the group, Simon, had ventured
into the Team’s work area to see their Sprint Burndown Chart, and called Francis
to his office.

“Francis, it looks like this Sprint is a disaster. What’s going on?” he asked.
Francis responded, “Well, the Team hit some bumps along the way, and they’re
trying hard to get everything done that they committed to, but it’s a bit touch-andgo
right now.”

Simon grimaced.

“Francis, this project is critical, and we can’t let it fall behind. I’m counting on you
to make sure the Team finishes what they commit to, this Sprint and every Sprint.
As a manager, your job is to make sure the Team gets it done; if things are going
well, then you can back off a bit, but the minute the going gets tough, I want you in
there making sure that no time is being wasted, and everyone is doing exactly
what needs to be done.”

Francis was exasperated. Simon had been too busy to attend the in-house Scrum
trainings, but Francis had emailed him a Powerpoint presentation about selforganizing
Teams and the new role of the manager, and Simon hadn’t voiced any
disagreement. Francis spoke up:

“But what about the self-organizing Team, Simon? What about our shift away from
micromanagement?”

There was a glimmer of recognition, as Simon recalled a Powerpoint he’d seen a
few months before.

“Yes, the Team is responsible, but when they start to fail, I hold you responsible.
We want maximum accountability, so I’m holding them accountable and I’m
holding you accountable. In our department, everyone is accountable! Now make
it happen.”

At that, Simon spun his chair around and started typing. Francis took the hint and
left the office.

The next day, Francis showed up at the Daily Scrum Meeting.

“Guys, we’re going to do a different format for the meeting today. Due to the
criticality of this project, Simon has instructed me to more actively… uhhh…
‘facilitate’ your self-organization during the Sprint. So what I’d like to do this
morning is get a status update on each of the features you’ve committed to –
whose done what so far, and what’s left to be done – and I’m going to be giving
some more detailed feedback so hopefully we can get everything 100% finished
by the end of next week.”

The Team looked at each other. Philip, the ScrumMaster of the Team, spoke up.

“Francis… uhhh… does this mean that the Team is no longer responsible for
managing itself?”

Several Team members nodded in agreement.

Francis replied, “Guys, we’re all responsible. You’re responsible for managing
yourselves, and I’m responsible for making sure you get everything done. We’re
all responsible together!” Francis didn’t see the eyeballs subtly roll.

As the Sprint proceeded, Francis was more and more involved. The Daily Scrum
became an update meeting for the Team to tell Francis what they’d been able to
complete, and for him to assign them the next day’s tasks. The mood of the Team
shifted; motivation seemed to go down, and Team members seemed to be
reverting to their previous role, what they used to sarcastically call “servants-of-
Francis-the-Great”. By the end of the Sprint, the Team was fully back into “orderfollowing”
mode, and Francis was directing their efforts task-by-task.

At the Sprint Review, the Team was surprised when Simon joined the meeting just
as it was starting.

“So…” Simon announced, “Did we get our commitment done?”

The Team looked at each other. Francis answered.

“Simon, unfortunately there are a couple backlog items that weren’t finished.”

There was a flash of anger in Simon’s eyes.

“How did this happen? Who is responsible for this?”

The Team was silent, but their heads all turned slowly to Francis.

Simon continued. “Francis, I told you to get it done. Next Sprint, I don’t want to
see this happen again. If it does, there will be hell to pay…”

Upon hearing this, everyone on the Team made a mental note to think very
carefully about just how much to commit to in the next Sprint. The last thing they
wanted was to get shouted at again two weeks from now.

As the Sprints passed, Francis became more and more involved in directing the
Team at every stage of their work. Gone was any semblance of self-organization,
and with it disappeared the improved motivation, drive, and focus that the Team
had started to display. Morale had plummeted, and so too had productivity. Lunch
breaks were getting longer, coffee-breaks more frequent, and Francis felt like he
was spending more and more of his time just making sure people were at their
desks working. Those amazing few Sprints, when the Team was truly selforganizing,
and performing at the level they were really capable of, were
becoming more and more of a distant memory. The return to micromanagement
was made all the worse because they’d had a taste of the self-organization “good
life”.

Here is a really cool chapter I just read out of the book “The Software Project Manager’s Bridge to Agility”

Almost brought a tear to my eye.

How One Project Manager Crossed the Bridge

I’m Stacia Broderick, and I want to convey a deeply personal story of
change in hopes of helping you recognize the importance of listening to
yourself and learning how to grow, even when it is quite uncomfortable and
scary.


I have been a project manager since 1993, agile since 2003. I am also a
PMP, formally trained in the lexicon of the thousands of certified Project
Management Professionals who went before me. When I started managing
projects, I took certain pride in my abilities to plan a project, learned how to
enter data into a project management tool, held status meetings, negotiated
with contractors and third-party sourcing for resources and materials, mitigated
risks in the project and, of course, controlled scope. I could perform
forward- and backward-pass calculations in my sleep.


Project management was a perfect fit for me, who, as a third-grader,
resource-loaded my two sisters and I into weekly rotating chore schedules. I
even designed a process for reducing the number of dishwashing loads by
only emptying the dishwasher based on a pull-and-batch system (pull a dish
only when needed, and no more frequently; gather all dirty dishes in the
sink until time to reload dishwasher; reload all at once), but my father did
not support this new approach. For me—a self-admitted control freak—
project management was a perfect fit.


My conflict with Scrum, one of the agile approaches to software development,
began in 2003. I was vehemently opposed to this new, lightweight,
not-sponsored-by-any-formal-governing-body methodology (or so I had
thought). My life was turned upside down when Ken Schwaber came to
train and mentor our team of managers and software developers. As a
devout PMP, or perhaps as a result of still being relatively new to software
development, I was a bit leery of Ken’s initial teachings about self-managed
teams and iterative development. As I drifted in and out of the two days of
ScrumMaster training, the line that caught most of my attention was, “You
have no power.” Ken meant it in the sense that the product owner and delivery
team roles would be collaborative in nature, and that a project manager
wasn’t the decision-maker in Scrum. Like a mantra, I repeated this line to
see if I could get used to it. I kept thinking, “How could you possibly manage
a project or people without power? Wasn’t it a prerequisite that you had
to muscle your way through a project and demand that people work overtime
and weekends (but promise to feed them free pizza)? As the project
team grew fatter and physically slower, didn’t this mean you could more easily
beat them into submission?” (I kid, I kid.)


When my boss failed to show up to ScrumMaster training, I was automatically
thrown to the lions as my (now ex)-boss’s replacement. Congratulations
to me: I was the newly minted ScrumMaster of three project teams.
Wow. So now I had to lead people. I had never lead people before. I had
certainly managed them, and collected the status of their tasks, and quizzed
them on how much time was remaining on those tasks. And, of course, I
questioned their estimates. (Everyone knows that developers are horrible
estimators!) I sometimes even gave my helpful opinion on whether certain
technical tasks were easy or difficult, much to the developers’ delight, I
am sure.


Of course, what I didn’t realize at the time was that I really had no
power to begin with. You see, I had always managed a group of knowledge
workers—folks who grew up crunching numbers, writing complex code,
creatively banging out products that at their roots consisted of only 1s and
0s. I truly believe that up until learning to lead, these knowledge workers
merely tolerated me. I had never really managed them. They managed me by
deciding to make me happy by filling out their timesheets. They humored
me when I asked to be walked through the testing phase of the project plan,
again. They certainly knew way more about how stuff really worked than I
did. My life was ruled by impossible project plans (see Figure I-1). For a few
months straight I made great overtime by staying late at the office to perfect
the Gantt chart, knowing in my heart that it would be out of date the very
next day, if not the very next minute. Often, I was asked to “create a dashboard”
for the executives: a report that I knew reflected a false, positive reality.
Now that I look back, I wonder how I survived the “manager” title.


My first thoughts turned to tracking the status of projects. How will we
know “where we are”? How will we know how much value we’ve earned?
(My CEO at the time had written a book on earned value management.)
How will we manage scope? (I had produced a scope change management
process for the department and had spent weeks perfecting the diagram.)
Most frightening of all, I wondered how insane our customers would think
we are since we’d no longer be able to tell them when they could have everything
they wanted. And what’s with the paltry Scrum project tracking mechanisms?
A burndown chart? What does that possibly tell us? That can’t
possibly tell us if we’re on track! I want my percent-complete status reports!

And let me say that the first few meetings with executives were disasters. I
know that I left red-faced on many occasions.


All of these questions were fueled by the personal struggle I was going
through: “Wow, if teams are self-managing, they’ll no longer need me.
I don’t have a place in this organization now that we’re using Scrum.” I had
no idea how to act within this new realm. I had a very real struggle with getting
past the “me” and focusing on the team. I was also troubled with
ownership issues. I routinely struggled with not owning the administrative
task of updating the product backlog; for me, this represented scope, and
not having it within my charge was very frightening. I felt powerless and as if
I had no role.


Somewhere around the third sprint, I started to get it. Once the teams
started delivering real value that could be seen and touched, the light bulb
went on. What were once yelling product owners were now engaged, energized
product owners, who actually worked with the teams to talk about the
user experience, helping developers deliver valuable product increments.
Observing collocated team members who were often heard laughing, working
closely together, and enjoying their personal lives again touched me in a
way that no perfectly calculated project Gantt chart or nested work breakdown
structure ever could. I began to realize what it meant for teams to
work at a sustainable pace and to focus their energy on what really mattered:
creating software for the company that they work for, while being able to
enjoy their personal lives the rest of the time (after all, isn’t this the foundation
that keeps us all sane?). Coupled with a VP who “got it” and banned
overtime for the department, the agile principle of sustainable pace really
lifted morale and improved the quality of work life. I even had time one
evening to visit the home of one of our developers, meet his wife, and learn
more about real Indian food. It was a wonderful, personal experience (and I
now love soan papdi, a wonderful Indian dessert).


After my personal light bulb went off about the value of agile development,
I began to realize how I could provide value as an agile project manager.
First of all, I let go of the backlog, and it relinquished its grip on me. By
doing so, I gave control to someone else, namely the product owner, and let
him prioritize the list. This gave me more time to focus on building teams. I
moved into the collocated space with one of my teams, and I worked on justifying
budget for other teams to collocate (and succeeded!). I created a
newsletter for all of the project teams, called the Daily Collaborator, that
included photos, stories, and interesting facts about the project. I learned
how to report to executives, which was no small feat, by understanding their
needs and by asking the team to help me determine how to show the project
data. I made sure that stakeholders were involved in product reviews; sometimes
it was difficult to get their time. I involved people from training and
support in our iteration reviews and garnered their support in the testing lab
when we were manually testing part of the system. I helped set up product
backlog meetings that replaced our traditional change control meetings. I
worked with customers as they implemented early releases of our products
to gather feedback and understand how we could improve their experiences.

And when I was in a period of quietness, I observed, observed, and
observed some more—in the team rooms, daily standup meetings, reviews,
and general team interactions. These observations helped me determine
which obstacles to tackle next; I kept detailed notes and added tasks to my
own impediment backlog when I saw a change or an organizational impediment
that needed attention. I was a chameleon and a peacock at the same
time, retaining the ability to blend in with the environment, while standing
out and displaying my feathers when the environment needed to change.
We celebrated a very successful release nine months after instituting
Scrum. It was a proud moment for us all; we had each traveled a personal
journey and transformation unlike any other. Our release t-shirts said
“Develop with Heart; Deliver with Pride.” That department of 85 people
always will remain my fondest memory of a truly performing Scrum development
organization.


My first three Scrum teams—the ones that truly scared the bejeezus out
of me—will forever remain in my heart as the kind people who taught me
the tough lessons of letting go.
The best day of my professional life was the day that I walked into one
of my Scrum team’s daily meetings and the team looked at me, smiling, and
said, “We don’t need you here, Stacia. Maybe you can use this time to work
on other things or to help another team. We’ve got it under control.” And
you know, they did have it under control. I walked away on the verge of
tears, but the tears weren’t for me and my “loss”; they were from the happiness
I felt at being able to let go and know that all would be just fine, and
from the satisfaction I felt from helping individuals become empowered.
For me to cross the agility bridge, I had to understand what it meant to
put others before me. This wasn’t something that came naturally to me;
because of a tough upbringing and lack of sense of self, I created a strong
identity in my project manager title. I had to learn how to facilitate and listen
for problems underneath the surface. Most importantly, I had to learn that
the people doing the work know the work the best and will figure out the
best way to get from point A to Z. All they really needed me for was to clear
the path. They knew this already; Scrum helped me see it.


Whereas Michele got it right away, it took me awhile. We each came
from very different places when embarking on our own personal bridges to
agility. Michele’s bridge was short and level; mine was a swaying suspension
bridge, on a 45-degree angle, fraught with high winds and torrential downpours.
What we both agree on is that since we’ve been helping teams—hundreds
of teams—move to agile methods, we have never been happier in our
professional careers. In the following chapters, we are pleased to present
some ideas for translating what you already know about managing projects
into your own agile paradigm. We’ll dig deeper into what you should expect,
how to successfully make the transition, and what steps you’ll need to take
in order to cross the bridge to agility.

Ajax Annie made a comment on my last post suggesting that there could be resistance to agile due to suspected lack of up front design and documentation. 

First I'll give you my honest answer based on past experience - as opposed to a prescribed agile methodology answer.

You know when you write a functional specification how they are typically based off a template of some sort with every conceivable project facet known to man kind? When I have written these in the past - 20% of the document is the gold and the other 80% feels like pure space filler. Based on template headings it becomes easy to create an impressively bloated document that doesn't actually contain a lot of useful information and this annoys me.

You read the average func spec and a lot of it is typically unneeded apart from the occasional good bit that you don't need to skim over - unfortunately the other 80% still takes time to write so the good bits can be glossed over due to time/budget constraints so that the rest of the document can be written.  

Why not just really focus on the good bits - the architecture design, how everything fits together, and make those parts even better and not kid ourselves that anyone will actually find the rest useful even though it looks good on paper. It would be great to have the freedom to simply write what is truly useful without feeling compelled to wrap it with suffocating red tape and words. They always look so good and acceptable however once done - but once the project starts I've rarely seen them referred to, apart from screenshots and expected behaviour on each screen.

Even architecture design (unless it's a high level diagram) I find hardly any new developer on the project would need to read it - we are coders, the real and current architecture is documented right there in front of you (and here is a secret truth - I think that all developers actually subconsciously assume that documentation will be out of date - so purposely do not look at it). Scary blow to the head for many PMs I think but I think that's the reality. 

The architecture may also evolve overtime - no design is ever perfect without the hindsight of what is learnt from actually starting the project.

I think the time would better be spent doing a spike or prototype of what you are wanting to build - that includes a piece of functionality that requires the core parts of the architecture to be there. The architecture of what emerged can then be documented in the planning document (I think at a high level). You were bound to have found things through that short experience that you couldn't have predicted on a bit of paper. You could even put this spike/prototype through some performance tests and deploy it to infrastructure similar to the target environment to prove that the solution is going to work before committing to it in a "plan".

As for a complete schema diagram of the entire application before development begins - yuck. One, I find developers just ignore them anyway and make up their own tables and columns as needed, very naughty, however a lot of the time, these end up being just as good or better - because they are closer to the problem at hand. Why do we need to pre-design this? Wouldn't it be better to just communicate to the team database schema changes in daily stand ups so not only one mind is on it, but many?
Isn't it true that there is normally more than one great mind on a project and that if the whole team is involved then there might be a much higher sense of ownership? Couldn't the same almost be said for the rest of the architecture in general as it materialises? Is this really uncontrolled? The same people/person that was going to make the initial decision themselves is still there with input and evolved design can be documented after each decision, which at least will be correct, non-outdated - and the best decision that matches the system to date.

Also, no one ever follows the original plan to the dot if there is now a better way apparent (and if they do, there is something seriously wrong). This is because the team can take advantage of truth based on experience so far in the project and ignore silly design simply due to the initial unknown.  Then you might think, why waste too much time on this initial design if it is all going to change anyway once the project has some legs behind it. 
If that makes PMs nervous - then they probably have a false sense of security about the guidance a detailed up front functional spec provides to a team that normally just prefer to work it out on their own with guidance from a tech lead or peers at the time in a more current world. 

I probably went too far the other way - but I wanted to stress the devils advocate to break some typical ways of thinking. An initial sense of direction and plan is definately a good thing. 

Here is how I think of agile - I believe the most efficient way of developing software is a group of friends getting together and just working stuff out and working together with passion - and that seems to transpire a lot to how agile methodologies work. There needs to be an interface above this however to engage with clients so that clients feel comfortable about things, a lot of the time due to lack of trust.

I think the aim is to make sure this interface however does not impinge too much on the most efficient way of developing software. I would love to break the mould and just think without preconceived ideas, what feels right and natural. Then make accommodations where necessary.  

We have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

-- From http://agilemanifesto.org/