Scrum in the Waterfall at DigitalPM 2013 (slides)

I've posted slides from my presentation at Digital PM 2013 here.

Digital PM Summit 2013 - Day 1 Recap

Day 1 of the inaugural Digital PM Summit is in the books and it was impressive. The event is being held in Philadelphia and is billed as "The first conference for a community of people who manage all things digital". I've attended and spoken at a lot of IT and PM related conferences in the past and there is definitely something unique going on here. There are a lot of conferences that focus on design and a lot that focus on development, and what they offer covers a wide range of subject matter and are delivered in a variety of formats. There are also a lot of PM conferences that focus on project management from the more formalized approach to managing work. And there are the Agile conferences which cut a slice across those areas. However, those conferences don't really speak to the audience that is present here in Philly this week. For the folks who manage projects at digital agencies, there is a different need. The agencies tend to be small to medium sized businesses with projects that can last anywhere from a month to a year (on average). The teams tend to be smaller in nature and many of them are caught in a space where a "just do it" can work for awhile, but it brings a lot of the pains you'd expect (stress, marathon last minute efforts, and technical debt). They could go the route of moving towards a more formal approach (like PMI), but the process burden doesn't really fit with the needs of the client or the work culture. They could also address a lot of their challenges with Agile, but this is not an ideal fit for many of their clients who are often more traditional minded and aren't compelled to change. So, what they end up with are a need to be able to manage work using a variety of approaches based on the needs of each specific project and client. At a larger organization (upwards of 50), it might be possible to bear the overhead of staff who are expert in different areas and approaches, but most of these organizations have a more lean approach that requires them to be able to develop a broader range of options in how they manage work. Coupled with that is the fact that the medium they work in is in a constant state of flux and they are expected to always be on the edge of what is the new, best way of designing things that leverage the latest tech.

The PMs in this space have to have one eye on design (maybe one and a half) and the other eye on technical practices. And somewhere in the middle, they still need to develop PM skills. Going back 10-20 years, my experience in this space was that the project management side of things involved a lot of floundering around, establishing a new approach every time things went really side-ways. The agencies that garnered all the attention back in the boom were places like Razorfish that kept a keen eye on the design side of the medium. That was, and remains, a valid approach, but this field has grown and evolved and is hungry for a better way. Unfortunately, none of the primary options can holistically solve the challenges they face.

What I have found to be truly unique about this event is the programming and the attendees. The way yesterday began offers a great example of what I believe makes this event a valuable and interesting alternative. The day started with Jeffrey Zeldman giving a talk that was rooted in design and UX standards. It was followed by Jared Ponchot that also skewed towards design as well, but dealt a lot with the creative process and how to approach creative work. The third speaker was the Conference Chair, Brett Harned, who gave talk called "How to be a Better Project Manager". Each of these talks would be at home in a variety of separate conferences, but putting programming like that together for this sold out event is what set the tone. These are not PMs who want/need to spend an hour learning about a better way to do Earned Value or, Critical Chain or managing projects that deal with Sarbanes-Oxley, CMM, ISO or (insert process here). These are design centric PMs who are deeply involved in the creative process who, while they may not self-identify as servant leaders need an approach that enables and supports their creative and technical leaders. Agile has a place here, but these folks are not Agilists. Traditional practices have a place here, but these folks are not PMPs (mostly). They are also not (mostly) designers or developers. They are creative PMs in the digital space. While it would be great to be able to develop expertise in each individual area (design, development, traditional PM and Agile), the years of work that could take would definitely be at odds with the realities of serving their clients.

One of the things I found most impressive yesterday morning was that for during the first 3 talks, there was the level of attentiveness and engagement of the people present at the conference. That is not to say that people who attend other conferences aren't engaged and attentive, but this was different. My experience has been that at a traditional PM event, career PMs look for a few new ideas and go to validate what they think they know. At an event like Øredev, technically savvy knowledge workers who are more on the advanced end of the spectrum go to be challenged with new ideas and ways of working that are often a few years ahead of the curve. At an Agile Conference or Scrum Gathering practitioners of Agile get together to work on how to get better at applying Agile. What I saw yesterday was a room full of people who were all there to find better ways to help the work that are fully respectful and supportive of the creative and technical process. They were not so much looking for ways to change how others work, but more for ways to change how they approach their own work.

Five or ten years ago, I'm not sure if something like this would have sold out so quickly to an audience that includes attendees from all over the US and some from Europe as well. But this community of Digital PMs is a segment of the PM community is definitely hungry for the opportunity to share and hone their unique spin on the field of project management.

Kudos to Greg Hoy, Brett Harned, Allison Harshbarger and the folks at Happy Cog for having the vision to create this event and for having done such a great job with it. #bigdamnheroes

Language is a virus from outerspace

William S Burroughs by Gary Schoichet

"Language is a virus from outerspace"
 William S Burroughs

Language is a tricky thing. It is a broken, imperfect system of encoding and decoding a message. If the encoder and the decoder have the same key, the message may be heard and understood as it was intended. If the encoder and decoder have different keys… bad things.

The encoding and decoding takes place on many levels and often carries around a lot of baggage.

If I am in a conversation and someone says:

“Yo, hand me that jawn over there. “

It probably means they are from, or have spent a significant amount of time in Philadelphia.

If someone says:

“We need to assign some resources to work on this project.”

It probably means they have been trained to manage or work with projects using a traditional (waterfall) approach.

When I took my CSM training I sat in a room full of 40 software developers. When I referred to people as “resources”, they boo’d me... literally.

In Agile, and in traditional project management we both use resources on our projects. But, because Agile takes care to focus on “Individuals and Interactions”, resources are generally considered to be things that do not have opposable thumbs and a capacity to binge watch five seasons of Breaking Bad in a 3-day weekend.

The way we use language infects our interactions with individuals. In this TED Talk, Diane Benscoler talks about being deprogrammed from the cult she had joined as a young woman. In the talk she refers to a “viral memetic infection”. This is, simply put, how language can be utilized to hack the brain.

In working with people on a project, if I regard them as individuals I work and interact with, I am likely to behave differently towards them then I would if I were to regard them as resources I expend to get work done (like a stapler). This can appear in very subtle ways – or, at least, ways that seem subtle to the non-Agile.

When I first began working in Agile I stumbled over a lot of similar encoding/decoding issues. The more experience I got with it, the more I learned how important it was to translate ideas before they passed my lips. As I would speak with someone about the project I was still thinking in waterfall, but speaking in Agile.  I’d think “resources” but say “team members”. And that helped a little. At least, I thought it did. To other PMs, it sounded very Agile, but being a little further on with it now, I do feel it is fair to say that language aside, intent shows through. If I am thinking “resources” but saying “team members”, the fact that I have not truly bought into the Agile mindset still shows through to those who do think of individuals and interactions.

http://www.acminc.com/wp-content/uploads/festrunk.jpg

If you are in the process of trying to transition from traditional to Agile, it is important to bear this in mind. There is often a significant difference between how we perceive ourselves and how we come across to others. I may believe I am able to fit in with the Agile folks once I learn to speak their language. Certainly that is a massive improvement over not doing so, but being able to speak the language and adopting the behaviors and value systems are not the same thing. One may lead to the other, but being aware of the fact that it is an ongoing process is an important art of not destroying your credibility along the way. 

An Interview with Mike Vizdos

I had the chance to interview Mke Vizdos for a podcast recently. You can find it here.

Even if you aren't familiar with Mike, there is still a good chance you are familiar with his work. Here is a list of some of the things he's been up to recently...

Mike Vizdos is  ____(please select from below)____________ 
 X  A Father of two great kids and Husband of an incredible wife
 X  A Certified Scrum Trainer
 X  An Agile thought leader / author who has been talking about enterprise level Agile adoption since before it even occurred to most of us
 X  All about Implementing Scrum
 X  Entrepreneur
 X  One of three guys in a shop working with Lean Startup 
 X  Co-founder and Community Builder of Gangplank RVA  
 X  Podcaster (will link to)
 X  Author of a children’s book illustrated by his son
 X  Founder of Real Scrum Jobs (will link to)
 X  A really nice guy
 X  Way busier than you…
 X  A walking example of how following your passion around certain areas of focus can help you establish an agile work life that is creative, experimental, invigorating, and of course, full of failure in the best possible way.
 X  Is working on applying what he learns daily using “this” cartoon as a reminder:

Generation Agile

When I posted on twitter earlier this week about the presentation my wife and I gave at the Global Scrum Gathering, Paris 2013, on The Agile Girl Scouts, a friend of mine asked me to put some context around it. He was able to understand that this was a pretty big deal to me, but was't sure why. My hope is that this blog post will provide some explanation around that.

The Waterfall

Most adults in the workforce today have learned how to manage work using a waterfall model. That means work follows something along these lines:

• Initiation - We figure out what we need to do

• Planning - We figure out how we are going to do it

• Execution - We do it and try to follow the plan as best we can

• Monitoring and Controlling - We check to see if what we delivered is what was wanted

• Closing -  We shut it down and capture what we've learned along the way.

Bag of Oranges Days

For many of the people who adopt this method, success comes from a command and control approach. This approach tends to view people as "resources" which are expended on a project to achieve a specific end. In the IT space, it has a history of being successful about 30% of the time. For the person acting as Project Manager, it often leads to a lot of "bag of oranges" days.

When I learned and later began teaching this model, I kept wondering why no one had taught me that stuff before. The simple tools it provided, seemed more like common sense. Just having the simple capacity to see an overwhelming amount of work and have the basic tools to break it down into manageable, workable elements was very enlightening. Since then I have been looking for ways to go back and teach my younger self some tools that would have made life a lot easier. 

Those tools were great, but using them was a bit like Frodo putting on the ring. The more I used them, the more I started to feel that I was supposed to try and control the uncontrollable and the more I started to view the humans I worked with as "resources" and not people. They were pawns on a chess board and I was playing chess against an opponent I could not hope beat because the only thing I could be sure of was that whatever I was able to imagine, predict, or plan for, was the only thing that was not going to happen. 

When I entered the workforce and started to work for people who had been taught that success came through control, I was often the pawn on the board. In many jobs I was micromanaged, condescended to, accused, blamed and generally treated like someone who could only be counted on if they were bossed around and threatened. I, in turn, reluctantly learned this approach and tried, to apply it (with limited success). This didn't happen all the time. I was lucky to have a few really great bosses and teams along the way and I was fortunate to find myself in situations where I really was able to be creative and collaborate with other people who cared as much about the work as I did. Those moments were invigorating. 

The Agile Manifesto

As part of a response to the waterfall approach, in 2001, a bunch of smart guys got together and came up with the Agile Manifesto, which says: 

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work 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.

In my journey towards adopting the above and learning to use the models and frameworks which support the Agile Manifesto, a lot of what I do is a reaction against the traditional command and control approach I had been taught.  I often joke that I am in a state of recovery, but I do tend to view it that way.  One of the reasons I get so much joy from what I do for a living is that  I get to help others on their transition as well. But I do think it is important to acknowledge it as a corrective action. 

Hope for the Future

Any parent wants their child to have a better life than they did. We all want for our kids to experience less adversity (or at least different adversity) than we did. If Agile is about creating a work environment that values people, their ideas and ability to collaborate in an effort to deliver higher quality work, then it is a very positive and healthy response to a workspace that did not support creative collaboration and self-organization. 

Each new generation finds that certain things which were common in previous generations, are no longer good for us. When I was a kid we'd go to the Jersey shore in the summer. If my Mom was able to get some Coppertone SPF2 or 4 on me it would only last until I was able to get to the water and scrub it off. I'd play, swim and lay in the sun until the blisters formed. The blisters were an indicator that maybe it was time to put on a t-shirt, a baseball hat, or in extreme cases, SPF 15. My daughter has been spared that due to how much more we know about the damage the sun can do to our skin.

My goal with teaching Agile to young people is similar to educating them about the dangers of too much sun. My hope is that if they learn about Agile first, their experience with it and exposure to the benefits it can provide will "inoculate" them against some of the challenges they would otherwise face if they entered the workforce as "resources" to be used up on a waterfall project. My hope is that they will see Agile not as a response against something else, but as a natural, organic way for empowered, creative people to deliver high quality work. 

Ninja, Baker Priest

In the Agile and Scrum classes that I teach, one of the topics that seems to cause a fair bit of stress, or at least, more than it should, is Cross-functional Teams. The stress tends to be rooted in a misinterpretation of what cross-functional means.

So first, what it doesn’t mean is that everyone on the team has to have the exact same skill set.  That would probably make finding people to work on the teams pretty tough. Everyone has things they gravitate towards and develop a certain amount of expertise in. Finding a really talented graphic designer who can code like Neo and is still willing to write documentation is unlikely. But we still want to have a team of people who have some ability to help each other out.

When I think about these things I sometimes find it helps to consider it outside of the context of Agile and Scrum.

Example 1: The A-Team

In 1972, a crack commando unit was sent to prison by a military court for a crime they didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government they survive as soldiers of fortune. If you have a problem, if no one else can help, and if you can find them .... maybe you can hire The A-Team.


In the A-Team, everyone has a role:

Hannibal – the Planner and Visionary
Face – The Master of Disguise (and Social Engineering)
Murdoch – Pilot of anything that can fly and team Wildcard
BA – Wheel Man and Muscle

Now, BA hates Murdoch. Actually, that’s not really true. BA pities the fool. He does not trust Murdoch because

1) Murdoch is certifiably insane 

2) BA hates to travel by air. 

So, every time they have to fly, Face or Hannibal has to slip BA a mickey finn or a needle and put him out.  While he out, they travel by air. When they land, someone has to drive. This role typically falls to BA because it is his primary area of expertise. However, if BA is still knocked out. Someone else has to drive. The other team members do not necessarily have to be as good at driving as BA, but they have to be able to drive well enough to get from A to B and possibly evade some law enforcement along the way.

Example 2: Ninja, Baker, Priest

Let’s say you have a team comprised of a Ninja, a Baker and a Priest. As part of the work they have committed to for the Sprint, they are responsible for taking steps which will result in the death of Mr. X.  Since the team has a Ninja on it, this should be no problem at all. But what if the Ninja comes down with a terrible case of the sniffles. He (or she) can’t exactly be a silent agent of death if they have to stop and blow their nose every 5 minutes.

So, the team has a meeting and discusses the situation. It is agreed that the Ninja should stay home, have come chicken soup and try to get better. In discussing the work, the Priest and the Baker agree that between the two of them, the Baker has the most experience with knives, so he agrees to head out and complete the contract on Mr. X. The only catch is that the Baker also had work to do. Fortunately, the priest has been well trained and has been known to be able to do some pretty cool stuff with Bread too, so he will help the Baker while the Baker is helping the Ninja.

So, the idea of cross functionality is that the team has or develops the ability to help one another when they need to. It is not that everyone on the team develop the exact set of skills. Once they have made a commitment, they are responsible for meeting it. If everyone on the team has a specific skill set that is not shared, a smart team will take some tome pairing or cross-training to remove single points of failure.

This is just a simple explanation. For me, these kinds tend to work the best. If you’d like something that digs a little deeper on this topic, I’d recommend checking out Heinrick Kniberg’s post on Crisp.

Agile 2013 Interviews - LeanKit CEO Chris Hefley

BigVisible Interview with Leankit CEO and co-founder Chris Hefley at Agile 2013 from BigVisible Solutions on Vimeo.

Agile 2013 Interviews - Jim Elvidge

Jim Elvidge at Agile 2013 from BigVisible Solutions on Vimeo.

Agile 2013 Interviews - David Bernstein

David Bernstein Live at Agile 2013 from BigVisible Solutions on Vimeo.

Agile 2013 Interviews - Ron Jeffries and Chet Hendrickson

Agile 2013 Podcast with Ron Jeffries and Chet Hendrickson from BigVisible Solutions on Vimeo.