Tag Archives: agile

Project Managers need agility regardless of methodology

by

My Sunday morning peruse of Twitter led me to a blog post ‘Agile Project Manager’, It’s a Contradiction. Despite being a little taken aback, I did click through and read it. And I whole-heartedly disagree!

I’m going to start my response by first looking at some definitions.

Methodology – Merriam-Webster defined it as “a particular procedure or set of procedures.”

Waterfall – Wikipedia defined it as “a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases.”

Agile – Wikipedia defined it as “a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.”

Process – Merriam-Webster defined it as “a series of actions or operations conducing to an end.”

Principles – Merriam-Webster defined it as “a rule or code of conduct.”

In project management, both Agile and Waterfall are considered project management “methodologies” used to deliver projects. They provide a set of guiding principles for getting results, and delivering business value. They both have pros and cons, and each is not right in every situation. Many times, a hybrid approach is needed.

Regardless of approach, a good project manager needs to be incredibly flexible. They need to understand the dynamics of all stakeholders, grasp the complexities of the value proposition and manage the situation throughout the process, adapting to the changing landscape. I would argue that even when using a waterfall methodology, a good project manager must be nimble.

It saddens me that the author of the aforementioned blog post feels that project managers “belong purely to highly planned deliveries where any change is a hinderance and fluidity is frowned upon.” Have they not ever worked with a good project manager that adapted to the movement of the project? Or have I just been incredibly lucky to work in organizations that allowed me to adapt and morph the project, and my role within in it as I see fit? It didn’t matter whether I was using a waterfall approach or were working towards agile.

The author further states that an agile project manager is a hybrid role, comprised of multiple responsibilities on projects not large enough to all the prescribed roles. I prefer to work within small to mid-size organizations, however usually work on projects for very large organizations. I’ve not had the luxury on any project to have a person to fill every role. Additionally, I think there is some level of getting your hands dirty in analysis, value recognition and other aspects of the project that enable me to delivery the projects I work on.

the-best-laid-plans...

http://www.azquotes.com/quote/608738

The one area where we did agree is “The ability to adapt, morph and practically deliver is…the true spirit of agile delivery.” I would also argue that it is the true spirit of a good project manager. If we are not constantly assessing where we are against our goals, and making decisions about how we manage the project (across stakeholders), and making adjustments to our plans, we can’t be successful.

Scrum and the Art of the Obstacle Course

by

What do you need to get through a complicated, every changing software development project and a Tough Mudder obstacle course?  A great team is a good starting point.

This concept isn’t new.  Ken Schwaber and Mike Beedle talk about it in “Agile Software Development with Scrum.”  They liken building software to running an obstacle course.  “Agility, flexibility and adaptability are required to succeed (p 99).”  They argue that following a set plan won’t get you to the finish line.  It is the art of balancing everyone’s skillsets, collaborating at each step, and openly communicating that allows for software development success.  Schwaber and Beedle further push the point by emphasizing that the team needs to self-organize and lead the efforts.  A manager, project owner, product owner, or other stakeholders can only assist the natural order of the team.

This resonated pretty well against everything that I heard about the Tough Mudder, and similar obstacle course races.  The Tough Mudder started with a 30-something fit men demographic who could probably “brute-force” their way through many of the obstacles.  That demographic has evolved to include 80-somethings and more fun focused teams,  In all cases, it has become less about “brute-force” and more about collaborating on the best solution.  Competitors have challenged Tough Mudder obstacle creators by using obstacles in unanticipated ways.  Like the agile team, a coach is going to be able to provide minimal support during the actual obstacle course.  It is his/her job to prepare the team for the challenge and eliminate hurdles prior to show-time.

Having managed multiple software development projects, this approach seems pretty intuitive.  Each team member knows their strengths, weaknesses and skillsets.  They will also be first to see the challenges.  Therefore, it makes sense for the team to to manage themselves, with a coach to nudge them in the right direction.  This approach requires an incredible amount of trust between team members.  Once this is established there should be a cohesive and collaborative group to overcome the typical challenges in software development.