Self organising units - Optimum performance?

I've just finished reading Ken Schwaber's Agile Project Management with Scrum and I have to say I thoroughly enjoyed it.

This wasn't because it was a new revolutionary approach to project management, but more because it affirmed in my mind that I wasn't alone in my belief of self organisation of staff.

I've never been a big fan of rigid project methodology and generally found it served more benefit to management and their obsession with reporting rather than increasing productivity.

Earning the respect of your staff and then allowing them to prove themselves via their own work, independent of too much control, I've always found far more effective.

You may think this sounds easy and that it's simply a matter of telling everyone what to do and then leaving them to get on with it. Not so, self-managing from my perspective is a slight misnomer.

To ensure effective self management you need to provide all of the facilities and cultivate an environment to encourage good productions rates.

These facilities and environmental variables will include everything from suitable equipment through to trust. As a project manager it will be your job to ensure you do everything you can to provide these for your staff.

When talking about environment, I'm not just talking about office space, desk, chair etc. (although these factors do have their own importance).

Environment could include ensuring teams are not bothered by factors that should be outside of their sphere of distraction whilst working on a specific job.



By making the project manager the interface of all communication that isn't related to the work that the unit is completing, ensures their focus remains on the completion of the work.

Fending off client calls that could be dealt with by you, the project manager.

Dealing with other staff that may distract development or design teams with minor work that could be handled by others, should also be part of the project managers remit under these circumstances.

One of the hardest aspects of introducing self organising units it get everyone else within your organisation to agree to follow the basic rule of always using the project manager as the point of contact, rather than approaching the staff directly.

But also the essential component of trust that I've talked about before. A trust that you have in your team to deliver the work as briefed. Equally a trust they need in you as a project manager to understand your clients requirements correctly and then brief them accordingly.

To do this you need to return to my two key components of successful project delivery; communication and definition.

Working with self organising units still requires you to define the work that needs to be completed, in fact this becomes more important than ever.

Scrum refers to this work definition as a project backlog, but you can call it what ever you want, the name's irrelevant.

Once defined and agreed it becomes up to the the team to work at the backlog, discussing the breakdown and distribution of the work amongst themselves. Defining an expected delivery time for the work and then avoiding the micro-management of each task that most dislike.

The digital media industries are growing at a rapid rate at the moment, but in relative terms they are younger than the IT industry I've left behind. Several years ago the IT industry started the process of highly structured methodology adoption with the likes of Prince2 being hot favourites.

In many enterprise cases this was appropraite, but in others it was increasing the overhead of project management and delivery team work loads significantly and unnecessarily.

I can see this beginning to take a hold of the digital media industry and I hope I can play my role in avoiding this from occurring.

Don't get me wrong, there will be cases were a methodology such as Prince2 might be appropriate for digital media delivery, but in most it's more suited to internal project delivery of large scale projects where the end goal might be more defined and less likely to evolve during development.

I'll talk some more about the sometimes spurious default action of adopting project methodologies in another post soon, as it's quickly becoming a concern of mine.

But for most web based projects I believe the concept of self-organising units can work very effectively. Dealing with smaller projects that can change shape as they progress, self organising units are empowered to take what ever action they deem necessary to adapt.

As mentioned above, this doesn't mean that the project manager becomes redundant, far from it.

It just moves their role from a Gantt chart making, Prince2 compliant certified professional, to more of a clear talking and trustworthy protective manager that will ensure the delivery of quality products on time.

Isn't that what we're supposed to do anyway?


Related links:

Book Review - Agile Project Management with Scrum - Digital Signals http://www.digital-constructions.com/blog/2009/07/book-review-agile-project-management.html

Digital Project Management - The Communication Brief - Digital Signals http://www.digital-constructions.com/blog/2009/05/communication-brief-initial-project.html

Managing Expectations - Keeping Everyone Happy - Digital Signals http://www.digital-constructions.com/blog/2009/06/managing-expectations-keep-everyone.html

Have You Got Time - Project Managing Time - Digital Signals http://www.digital-constructions.com/blog/2009/04/have-you-got-time-project-managing-time.html

blog comments powered by Disqus

Book Review - Agile Project Management with Scrum

I've just finished reading Ken Schwaber's - Agile project management with Scrum.

Well worth the read, although a little pricey as is always expected from Microsoft's Press.

It was my first thorough read/investigation into Scrum, although I have done some reading into its basic premise on earlier occasions.

I've got to admit I was quite excited about what Scrum proposes, it was much more in line with my own beliefs on project management than many other methodologies I've read about.

I'm not going use this post to discuss Scrum and its benefits, I'll save that for another day. Instead this is a quick review of the book itself.

For those of you that know Scrum, you'll be aware that with Scrum it's relatively easy to explain the components of the methodology. It's the application of those simple components and rules that are significant.

With this in mind Schwaber doesn't go into great detail about all of the components involved in Scrum. Instead he describes an overview of the roles and delivery process in one of the initial chapters - Backdrop -The Science of Scrum; then leaves descriptive details to apply them to real life scenarios to all further explanations.

Considering the theory behind Scrum, this makes perfect sense. Scrums self organising units, empowering teams of individuals to complete projects through self managed plans of delivery.

Taking the book into real world examples enables Schwaber to detail some of the issues you may encounter when trying to implement Scrum.

To this end he goes on to describe each role within the process and issues he's encountered when trying to assist companies with their adoption of Scrum into their project teams.

He focuses on a selection of about 5 different clients that his worked with to illustrate the various elements and possible issues that you may encountered.

This allows him also to illustrate how flexibility is a core requisite of any Scrum implementation and the benefits this can bring.

It also allows him to deal with possible issues you may encounter when attempting to change management cultures that revolve around project delivery by more traditional structured approaches, such as Prince2.

Real life examples allow Schwaber to illustrate some innovative approaches that he's had to adopt in order to get management to accept Scrum as a valid delivery approach.

The book finishes with a number of appendices which detail all of the roles and related documentation that you can expect to produce during a typical Scrum life cycle or Sprint.

This is a more than adequate way of imparting these details rather than wasting time in the core body of the book.

I particularly liked the chapter that dealt with the Scrum Master role in the implementation of Scrum. It detailed a number of real life examples of which I've experienced very similar scenarios to in my career. The scenarios illustrate the mistakes made by the Scrum Master and what was required to resolve the situation.

There are also a number of notes that followed the publication of the book that cover how to implement Scrum with specific requirements; such as meeting Capability Maturity Model requirements.

All in all I thought the book an excellent read and it has certainly inspired me to adopt some of the ideas of Scrum to my day to day work.

Scrum would have worked well with a number of previous projects I've worked on within an enterprise infrastructure environment. It seems harder or less appropriate to implement with smaller projects within a web environment that may be completed within less than 30 days.

If I were to have any gripes about the book they would only be the price, a little sharp but always expected with anything from the Microsoft Press.

Perhaps also the editing of the book, I noticed a few editorial mistakes with repeated names in the wrong places and other very minor issues. Which when you're paying top dollar you would hope wouldn't appear.

Other than that, I would highly recommend the book to anyone thinking about Scrum implementations within their organisation; or for curious project managers that might just want to add another string to their bow of methodology knowledge.


Related reading:

Digital Project Management - Episode One - Introduction - Digital Signals http://www.digital-constructions.com/blog/2008/12/digital-project-management-episode-1.html

Digital Project Management - Episode Two - Project Acquisition - Digital Signals http://www.digital-constructions.com/blog/2009/02/digital-project-management-episode-2.html

Digital Project Management - Episode Three - Planning, Pitching & Acceptance - Digital Signals http://www.digital-constructions.com/blog/2009/06/digital-project-management-episode-3.html

Digital Project Management - The Communication Brief - Digital Signals http://www.digital-constructions.com/blog/2009/05/communication-brief-initial-project.html

blog comments powered by Disqus