Ever asked yourself how you could be successful with Agile at scale? Let me show you how we've done it at LeadingAgile. In this one hour session that I presented to the PM Symposium in Washington DC, I explained how we've been successful by focusing on culture last and predictability first.
Hawthorne Effect Coaching Dilemma
The Hawthorne Effect is something I wrote about over a year ago. Previously as a Project Management Adviser and now as an Enterprise Agile Coach, I've seen it numerous times. To all those currently advising or coaching, do you tend to see clients trying to impress you? The Hawthorne Effect refers to the tendency of some people to modify their behavior, when they know they are being watched, due to the attention they are receiving from researchers, auditors, or coaches.
This effect was first discovered and named by researchers at Harvard University who were studying the relationship between productivity and work environment. Researchers conducted these experiments at the Hawthorne Works plant of Western Electric. The study was originally commissioned to determine if increasing or decreasing the amount of light workers received increased or decreased worker productivity. The researchers found that productivity temporarily increased, regardless if the light was increased or decreases. They then realized the increase in productivity was due to the attention given the workers by the research team and not because of changes to the experimental variable. (Thanks Wikipedia)
This is one reason short term engagements can be challenging. People are on their best behavior, until they get used to you being there. This is also why I don't believe in annual reviews. How do you, as managers, leaders, coaches, or auditors get past the effect? How do you ensure you get a true representation of individual and team behavior and not suffer from the Hawthorne Effect?
Image Source: Pictofigo
Theory X vs. Theory Y
Do you lead or do you manage? Do you believe in command-and-control or do you believe in team empowerment? Recently, while presenting an Agile Enterprise Workshop, we discussed Theory X and Theory Y with our workshop attendees. Theory X and Theory Y are two extremes introduced by Harvard Professor Douglas McGregor in his book “The Human Side of Enterprise”. It was published over 50 years ago. Still, you can find both theories in practice today.
Though the theory of x and y are not absolute in how human nature plays out in our places of work, there will always be those among us who are polarizing and think of life as a side of a coin.
So, which do you believe?
Theory X and Theory Y
HT: Dan Pink
HT: Wikipedia
Organizing Around Teams
Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100 percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions? In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Two, team members never seemed to have time to just focus on one thing and get it completely done.
Status quo organizes teams around projects
- Projects are initiated
- We beg, borrow and steal, looking for the right people to work the project
- We pull a few hours from here and a few hours from there
- Everyone is "fully utilized" by working on several projects at the same time
- When the project is completed, we release some portion of each person’s hours back into the pool and start again
- Endless resource-management frustration
Bring the right projects to the right teams
- Teams focus on one or two projects at a time and get them done quickly
- Management prioritizes projects and queues them up for the appropriate teams
- May need to move a few people around but hopefully not many and not constantly
- Much of the resource management problem goes away
- We also get fewer simultaneous projects, more focus, and more speed of delivery
Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.
Organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.
Blending Scrum and Kanban
Though I frequent the LeadingAgile website, I have to do a little more than just retweet a link in support of this post. I've known Mike Cottmeyer a while now. The guy just gets it! For those who are new to Agile, Scrum, or Kanban, you need to carve out 10 minutes and watch this video. In his own words, Mike says he
blends concepts like Epics, Features, User Stories, Story Maps, Minimally Marketable Features, Scrum, Kanban, RUP, and even traditional SDLC to create a scaleable agile enterprise portfolio framework.
I wouldn't doubt that pretty much anyone who watches this video is going to have a light bulb moment. Recently, I've had quite a few people asking me about Kanban. Though I'm excited to tell them what I know and my approaches, Mike does an awesome job of both blending Scrum and Kanban and then communicating the approach in 10 minutes.
Head over to LeadingAgile and read some really great stuff. Also follow Mike on Twitter at @mcottmeyer