Tag Archives: scrum

Reflections After a Year of Agile Coaching in India

Posted on
15

Agile Coaching India

I started working in India full-time in August of 2010. As an American, I had a suitcase full of expectations and assumptions. After a year of working with Indian IT professionals side-by-side, it’s time for a few reflections and observations.

Scrum in India is HOT. Some 18 Months ago, there was only one reliable vendor offering Certified ScrumMaster (CSM) training in all of South Asia (Pete Deemer of GoodAgile.com), and he was based in Singapore. Now, there are three Certified Scrum Trainers based in Bangalore (Pete, myself, and Vibhu Srinavasan of Solutions IQ), and a Certified Scrum Coach in Hyderabad (Madhur Kathuria). Added to that mix is a spike in agile events, such as the quarterly Scrum Bangalore, the mulit-city Agile Tour, and the upcoming Agile India 2011.

India’s Talent is a Strength. There is an obsession in this country with education. Driving from my home to the airport, I see two to three DOZEN billboard adds for bachelors and masters programs. The kids that score highest on standardized scholastic exams are featured in front-page newspaper articles. It then extends into the professional world. An amazing 2010 book called The India Way highlights the dramatic difference between American and India with regards to talent. In America, companies find talent, but Indian companies develop talent. When I joined large companies like Bell Atlantic or Lockheed Martin as a young engineer, my orientation took 2-3 days. Here in India a new hire can spend up to 6 weeks in skills development training. But it doesn’t end there. Most large firms have a “learning & development” organization that hosts dozens of training programs at a time, which employees are required to take as part of their annual appraisal process. What that means is engineers in India are hungry. They are eager to learn and try new things if you let them. By far and away, Indian teams leave my agile training even more energized and motivated than their US counterparts.

Infosys boasts the world's largest employee training center

India’s Talent is an Impediment. All that positive energy around engineering talent comes to screeching halt after a few years of professional experience. Over the last 30 years or so, the West has fostered the concept of the technical career track. For example, at Marriott headquarters in Washington DC, I met a really smart yet simple man who retired in 2009 as a life-long Cobol programmer with a happy family. In India however, that would be considered a wasted life. If you are still programming after 5 years of experience then something is wrong with you. You should have been promoted to the higher-paying and higher-prestigious management role, where you could then provide a better life for your children. I had one test manager tell me to my face, “Taking the role of an agile team leader is a demotion, and my career won’t be able to survive that.” Yes, there is talk of a technical career track in India, but it usually means getting promoted as an architect or a professor who has long since stopped programming and now tells other engineers what to do. Also, all that free technical training is a set of golden handcuffs. As a provider of IT certification training, I hear many questions along the lines of “Why should I invest in my own career advancement, when every company I’m interviewing is promising me similar training at no personal cost?” This all adds up to a dramatic gap between mid-level engineers and strong senior engineers like Robert Martin describes as the crux of software craftsmanship. Those engineers do exist, but you should expect that your Indian agile teams consist of many motivated, but relatively junior engineers.

Global IT infrastructure is an impediment. Without a doubt the largest shock I have experienced is the atrocious support that multi-national software teams receive from IT infrastructure departments.

  • Some of it is simply multi-national business. The parent company in the West has its network domain, and the subsidiary in India has its network domain. Because they are two different companies, the workstations and servers often are not directly accessible to each other without jumping through VPNs, firewalls, and removing servers.
  • Some of it is cost pressure. One of my clients does not even issue proper workstations to its engineers, but instead has them remote into Virtual Development Instances. Shared virtual development workstations will save a few thousand dollars on hardware costs, but it yields competition for system resources, and more network latency on my coding and testing.
  • Some of it is just mean. Another client of mine is doing iOS development, but the IT department only supports Windows PCs on the network. One would think simply to do a manual sync of the source code to their macs, using a USB pen drive. BUT, the USB ports on their company-issued PCs are disabled “for security reasons”. I won’t say the hack these guys used to get their work done, but let me tell you it would make any sysadmin shiver in his bones.

Regardless of the reasons, it all adds up to wasted productivity. I estimate that Network latency + system resource latency + manually doing what a computer should do = 30-40% loss of engineering productivity. I blame the Fortune 500 CIO for this. His executive mandate is to cut costs, without regard to the ten times great loss of productivity and employee satisfaction. This means if you are dealing with distributed teams, expect IT infrastructure to be your number one issue. Worse than the time zone. Worse than the culture differences.

Everyone is doing it. Another misperception in the west is that only a small syndicate of evil CIOs have shipped jobs overseas. Here in Bangalore, a casual drive down along outer-ring road road will reveal the following firms: IBM, Perot Systems, CapGemini, Tesco, SAP, GE Healthcare, Oracle, Cisco, Intel, Accenture, and Dell. And that’s just eastern Bangalore. Other cities in India feature firms ranging from John Deere (Pune) to Microsoft (Hyderabad). After trading stories with my colleagues, I have learned that a surprising plurality of Agile coaches have made at least one visit to India in their career.

Even India is doing it. One American colleague asked me over dinner, “Jesse how do you respond to the challenge that, as a business agility coach in India, you are an accomplice to India’s sucking technology jobs away from America?” I was stumped by the question at the time, but the more I see of global IT, the more complicated the picture has become. For example, all the top Indian outsourcers have a significant footprint in the US (Wipro has 14 offices across the US), and one of them is even headquartered in the New Jersey (Cognizant). The biggest shock came way back in 2004 when India’s largest Telecom, Bharti Airtel, “reverse outsourced” its IT to IBM for $700 million. But now, it’s getting even more complicated: Last year, Airtel hired the New York based IT giant again, this time to support the Telecom’s expansion into 16 African countries. During the 2012 election season, we will hear a lot of politicians calling for a ban on outsourcing. But doing so may actually have a domino effect on current jobs in their own districts.

I’ve got other observations lingering around in my brain, but these are the first I wanted to share. What about you? What differences have you seen between the Western and Eastern approach to IT work?

Bangalore India Talks About Scaling Scrum

Posted on
2

NewImage.jpg

This week featured the latest gathering of Scrum prapractitioners in Bangalore. This free event drew a solid 50 participants for the second straight time, and featured some really smart technology workers. The group was about 50% developers, 25% testers, and 25% managers. I did get to do my standard presentation on Agile Contracts, but the broader theme for the day was “Scaling Scrum”. This was of great interest to me, since RippleRock is helping a large dotcom implement Scrum across two strategic pilot programs using 4 teams on 2 continents. Needless to say, I took copious notes below

Scaling Scrum

First off was Vibhu Srinivasa from Solutions IQ. People laughed out loud as he facilitated a team dynamics game. But what people came to hear were his points about using Agile techniques on really large projects:

  • Understand Why You’re Scaling – The point is not merely to have an official standard for managing work. The point is to create alignment across larger projects, to make sure people are on the same page about delivering on a business objective.
  • Understand What Scale Means – To help bring alignment to our own large group Vibhu offered this definition of large-scale agile projects: “A group of teams working together on a common product or project or portfolio”.
  • Well groomed backlog is required to scale Scrum. For a single team of 7 people, a poorly formed backlog will only impact that team. On a larger project of a dozen teams working on the same poor backlog of project work, then you’ve just scaled the associated pain and errors.
  • There are several ways to nest Scrum teams. In general you can have nested backlogs of increasing degrees of detail, but there needs to be a clear, singular owner of each product backlog.
  • Charter a Product Owner team, responsible to keep the backlog groomed and prioritized. In larger organizations, the Product Owner role can quickly get to be too much work for one person. Have relevant stakeholders meet as required, above and beyond any other meetings with the Scrum team.
  • Align the sprint schedules. Namely, it helps if everyone is working to the same deadline.
  • Use the Scrum-of-Scrums only to coordinate dependencies. The overhead associated with the Scrum-of-Scrums is best utilized less as a status meeting, and more of an impediment removal meeting.
  • Relentless Automation – Just scaling scrum management is not enough. You need continuous integration, low-cost regression testing, and  ”touch free” deployment.
  • Rotate ScrumMasters – Spreads skill and awareness of Scrum and alleviates anxieties about career path.
  • Ambassador Pattern – Fly people to their distributed counterparts for key meetings or even for an entire sprint . This help preserve team dynamic,  when individuals return to their home base.

Vibhu Srinivasan

 

Globally Distributed Agile Teams

Then, Rini van Solingen. the CTO of iSense Prowareness, joined the group over skype. He started off with describing the “30 meters principle”: When teams are distributed more than 30 meters apart, the communication frequency drops to near zero. So, it doesn’t matter if your 3 time zones away or 3 miles away, the real limit is 30 meters.

This is a bit of an obsession for Rini, who is working a research project at TUDelft called “Creating the virtual 30 meters”. In this research, he has found some best practices:

  1. If a single roof is possible, do it! Don’t distribute if it’s not absolutely necessary.
  2. First, deploy Scrum locally and effectively before working distributed.
  3. Assign Scrum roles explicitly. The Product Owner and proxy roles becomes even more critical.
  4. One team in one rhythm. Staff your regional teams with people from all other locations. This is the “ambassador pattern” described above.
  5. Meet. Teams are not built by themselves. You need to actively establish relationships by traveling to each other’s sites.
  6. Impediment removal and retrospectives are even more crucial. In fact, meet collectively for retrospectives (see previous item).
  7. Work at the customer location at least between 10-20% of the time.
  8. Personal mindset is crucial: “what did *I* do wrong? what can *I* do different? how can *I* help?”.
  9. Don’t focus on tools: discussion and interaction are more important.
  10. However, communication and awareness don’t happen automatically. Here, tools can help, but only if implemented with the right purpose in mind.
  11. Fail fast: improve empirically. Both success and failures are sources for learning.

 

Open Conversations

The day wrapped up with an open space session. A number of topics were suggested, but the top two were two key topics:

scrum-bangalore-open-space.jpg

 

  • Estimation: In this conversation, there was a lot of discussion about the expectations around estimates. Managers expect your estimates to be internally consistent, when in reality they aren’t. They also expect your actuals to match those estimates exactly, but in reality they were really just estimates. One suggestion was to begin using the word “forecast” instead of “estimate”. Doing so may emphasize the fact that the numbers are rigorous, but not iron clad.
  • Careers. Here, there was concern about the impact Agile roles and responsibilities have on your career. For example, if a developer takes the risk of helping lower-paid testers learn code-based automation, will that make him less needed? If a BA takes the risk of not writing all the details for all the requirements up front, how will her skill be judged? If we take the risk to move in the professional direction of Agile skills, is there a job market for those skills? The answers are not easy. If you work for bad managers, then they may punish you for doing the right thing. But then again, they’re probably already doing that. And really, the your career should not be based on a choice between Agile jobs or non-Agile jobs. Your career should be based on what makes you and your team most successful.

 

It was an eventful day. iSense does a really good job of organizing this. I look forward to the next one at the end of September.

Scrum Gets Going In Bangalore

Posted on
Reply

This past Sunday, May 31, 2010 saw the kickoff event for the Scrum Bangalore user group (photos available here). It was a 6-hour mini-conference that featured 2 speakers, and open-space, networking, and several prizes. Also in attendance were the Agile Bangalore user group, an online community led by Vinay Krishna.

Rahul Sah Kicks Off The Event

Scrum Bangalore is the product of Rahul Sah of the Dutch company iSense Prowareness. He started the event by setting a vision: there is a huge gap between the demand and the support for Scrum in Bangalore. He said that he was charged by Jeff Sutherland to start something, when it was observed that the most Google searches for “Scrum” originate in Bangalore, more than anywhere else in the world. Before this month, there were no formal user groups supporting the local Agile practitioner community in Bangalore; now there are two.

rahul-sah.jpg

 

 

Pete Deemer Wows the Crowd.

The headliner was long-time South Asian Scrum trainer, Pete Deemer. He shared with us his 19 keys to successful agile adoption. It was a great talk with lots of energy and insights. At the end of the talk, he amazed the group with several giveaways, including a copy of Mike Cohn’s latest book for *everyone*. A very generous gesture indeed. 

 

pete-deemer-book.jpg

 

The “Amriki Gaura” Gives it a Go

In the afternoon, I got up and introduced myself to the crowd, sharing my story of starting an Agile consultancy in India. I then facilitated a group discussion about how to overcome key challenges with Agile Adoption. We used the “12 Key Objections to Change” from the NY Times bestseller Switch (a great book I will discuss later). Both Pete and the group offered some excellent points:

  • Change is like a rebirth
  • Many agile teams are technically proficient, but behaviorally are still stuck
  • Driving in Bangalore is the essence of a self-organized system
  • Scrum is a paradox: we offer specific guidance on success, but must encourage the team to choose its own direction
    • 

facilitating-discussion.jpg

Agile India Moves Forward.

Afterwards, I had some drinks with the new leadership team of the Agile Software Community of India (ASCI). We talked about the 2010 spike of activity in India around Agile projects, such as:

  • Agile Coaches camp in Goa earlier this year
  • Launching of 2 user groups in Bangalore
  • Four (4) scrum trainers offering classes in India, instead of Pete Deemer being the only one
  • The forthcoming announcement of the Scrum Day India event in August

It is an exciting time to be a part of this community. And I’m looking forward to an eventful remainder of 2010.

QUESTION: What other signs of increased interest & momentum around Agile engineering or Agile project management are you seeing in India ?

 

The 19 Keys to Successful Agile Projects

Posted on
6

nineteen.png

This past Sunday saw the kickoff of the Scrum Bangalore User Group in Bangalore, India (more on that later). At the meeting, Scrum expert Pete Deemer gave us these 19 nuggets of wisdom from his many years as an Agile coach for organizations across the world.

  1. Do it for the right reasons: Like Harry Potter, when evil wizards use good magic for evil purposes, they get destroyed.
  2. Start with teams that want to try it: It’s counter-intiutive, but don’t force a pilot effort onto resistors. Have the teams pick themselves. Then, set their expectations: “Are you sure you want to try it? It’s really dangerous. You can try it, but only for 1 sprint”.
  3. Set realistic expectations for Scrum: Don’t go in saying, ”Scrum will save our disaster project”. Force a project restart & give the team 3-5 sprints of breathing room. That’s how long it takes to get to all cylinders/cruise control.
  4. Call it a pilot program for as long as possible: People assume a pilot is messy, and nor will a pilot threaten their long term career.
  5. Change is scary to many people: Humans aspire, in an unfriendly world, to protect ourselves with some stability and predictability. Introduce your changes gently: “Scrum may not be right for us, but we won’t know until we’v tried it. So let’s do it all-in, correctly, for 1 sprint. Did we see any benefit? If so, let’s do it one more sprint. It’s one way of working. It’s not the final way of working, but it might help us get a little bit better”
  6. Patience is a virtue: - Start with 1 team and grow gradually from there. You don’t want 20 teams all struggling with the same issue we’ve yet to figure out.  Instead, it’s better to have one trailblazer fix that issue so others don’t have to.
  7. Find the Scrum middle path: In some ways, my job is a purist advocating the dramatic change, speaking hard truth, but then encouraging teams to tailor the practices to their situation. Be careful though; many organizations respond to the pain of change by diluting the change.
  8. Scrum is hard: it surfaces your nasty, accumulated junk. If you’re not prepared to deal with the issues that Scrum reveals, then it will be very hard to continue.
  9. Get experienced help: Consultants are not afraid of getting sacked, nor do they have a departmental agenda.

pete-deemer-scrum-bangalore.png

  1. Get high quality training: Often, adoption failures are associated with the initial training provided by someone who was told to read a book over the weekend. Better to send 1 person to really good training, than to send 20 people to bad training.
  2. Your enemy is your friend: Spend the most time with the people that like Scrum the least. Put your chief resistors on the Scrum steering committee. If they’re not engaged, they’ll miss how it works, and feel marginalized.  Also, those resistors will help you understand the key roadblocks to successful adoption.
  3. Be prepared to use Guerilla tactics: Namely, if management won’t solve your problems, sometimes you solve them yourself. One example: get your own screwdriver and change the cubicles over the weekend.
  4. Find your guardian angels: You need senior managers who “get it”. When you need to bend a corporate rule or special budget funding, your guardian angel. Indeed, many executives are eager to try an Agile approach, because they’ve worked on so many project train wrecks over the years.
  5. Make good information more accessible than bad information: There is a ton of bad information on the internet about what an Agile approach is or isn’t. Establish a steady flow of good information with email updates, brown-gab lunches, staff meeting talks.
  6. Measure the results early and often: Publicize the good and the bad results. Have both business and technical metrics. Use surveys to measure both the customer’s satisfaction and the team’s satisfaction.
  7. The urge to tinker is great: To illustrate the difference between tailoring and compromise, Pete described a game of “CricketBut”. We play Cricket, but instead of a pitch, we’ll use my living room. Instead of a wicket, we’ll use my dog. Instead of a ball, we’ll use a brick. Instead of a bat, we’ll use my head. After a few overs, you will have bloodshed, just like at the office.
  8. Choose your tools carefully: Don’t ask “which tool should we use”, but ask “What problem are we trying to solve that makes us think we need some software tool?”
  9. Don’t stop with just the members of the Scrum team: Scrum is an organization framework. Often a team can be successful on a localized level, but the organization is stuck in bad habits and the success is not fully realized. You as a team might be able to deliver results, but if it doesn’t get out to the end customer, who cares?
  10. Scrum will always be messy: The Agile movement is fundamentally about people and what they do. If people aren’t perfect, then our projects will never be perfect either. You will always have conflict, mistakes, and challenges. Simply ask yourself, “is it better than it was last month”.

It was a lively talk, that yielded some good points. Pete has a witty energy about him that made the talk even more enjoyable.

QUESTION: what have you seen to be the keys to successful Agile projects?

Scrum Certification for DC Project Managers

Posted on
Reply

CSM in Rockville

I’m thrilled to announce that Excella will be hosting its very first public Certified ScrumMaster course in the Washington DC area.

We’ll be hosting the class in Rockville, right on the red line. I’m still negotiating with a couple candiate venues to ensure the best possible experience. Once I’ve picked a winning facility, I’ll post an update here.

Here are the details:

Scrum Gathering Turns Into Free For All

Posted on
Reply

Day 3 of the Scrum Gathering this week was a fascinating experience. The day’s events were run in “Open Space” format, where the agenda was completely self-organized by the conference attendees. First, everyone was invited to post their suggestions for a topic onto the wall. Then, all the others came to the wall to see what was posted. Finally, attendees would vote for and negotiate on their favorite topics.

Scrum Gathering attendees choose topics

Now, at first it may seem like a disorganized free for all, but in truth it yielded some excellent conversations…

“Why are Project Managers Considered Agile Outsiders?”
The first session I visited explored the question of why Project Managers are perceived so poorly by Agilists. Some highlights were:

  • ScrumMaster and Product Owner are not job titles or job descriptions, but simply roles within a project.
  • Serge Beaumont suggested we move our PMOs into "scrum support teams”
  • Scrum Alliance President Tom Mellor explained that in his organization, the PM becomes the chief servant leader of a project organization, offering organizational support to team ScrumMasters.
  • The grouped agreed that PMs transition to Scrum best when changing their identity from "manager" to "member of product X"

tom mellor suggest the project manager become chief servant leader

Agile Outsourcing
The next session explored the topic of Agile Outsourcing. Often, “outsourcing” is a synonym for “offshoring”. Accordingly, it was not surprising that this conversation featured practitioners from Bolivia, Costa Rica, Bangladesh, and India. All of us traded humorous insights on the differences in cultural norms. For example, I learned of the “Bolivian ‘Yes’”, which asserts the listener merely hears you, rather than fully agrees to your request. We also talked about contracts, and agreed that offering your clients iterative, incremental funding options could give you a competitive advantage.

international Agile practioners discuss outsourcing

Vibrant Knowledge
After each session, the topic owner would type up his notes from the talk and post them on the “News Wall”. This way, I could get the gist of any session I couldn’t get to. There were also ad hoc discussions in the hallway, creating a atmosphere of vibrant knowledge, moving from one person to the next, each transfer being enriched by an individual perspective.

Scrum Gathering proceedings posted on conference wall

If I sound somewhat energized by the experience, I am. By many accounts this was the best Scrum Gathering ever. Each day offered a different format for learning, keeping people engaged and interested. Each session offered a different mix of participants, keeping the content varied and rich. If you get the chance, I strongly recommend you go to one of the upcoming Scrum Gatherings in Shanghai, South Africa, or Europe.

Question: Did you go the Scrum Gathering? What was most enlightening or helpful about the experience?

Scrum Gathering Collides with Project Management

Posted on
2

Yesterday was day 2 at the annual North American Scrum Gathering (click here for the events from day 1). The day featured several tracks covering a broad array of topics:

  1. The Edge of Chaos (innovation, risk, cunning…) Host:  Jimi Fosdick
  2. Huge Scrum! (Massive implementations) Host:  Sabine Canditt
  3. Good Practice (e.g. coding, testing, collaboration, design…)  Host:  Michel Goldenberg
  4. Scrum in Context (what Scrum can learn from other industries and research, and what Scrum can teach)  Host:  >>Bob Sarni
  5. When worlds collide – Scrum and traditional Project Management.  Host:  Dave Prior and Mike Cottmeyer

When Worlds Collide

“Agile project managers consider Scrum teams their customers”

That is a quote from Sanjiv Augustine in his “Agile PMO” talk. This was the first full session of the day for the Project Management track. His offered some interesting models of what a more adaptive PMO should look like. For example, PMOs should be virtual committees, whose members work on and report to real projects.

image

 

PMOs All Around Us.

For the next session, I moderated a panel discussion on the Agile PMO. Since Sanjiv had just spent an hour setting a baseline of what an Agile PMO could be, it was time to get down and dirty with some different perspectives. The panel included:

There was some fun banter back and forth, but we all settled on some core points. First, the PMO should be chartered to enforce principles, rather than compliance. Next, metrics should be driven primarily by business levers, and only secondarily by cost/schedule. All of these experts offered great insights and are worth looking up.

“Agile Project Manager….or not”

Closing out the day, Lyssa Adkins offered a compelling presentation on moving “Traditional Project Manager Turned Agile Coach”. This talk offered some of the best observations about the Project Manager role, and they were posted on the PMI Agile twitter feed. At the end of the talk, Mike Cottmeyer gave an abbreviated Pecha Kucha version of his “Agile PMP” talk, which served as a dynamic counterpoint to Lyssa’s points. Then, at the end of the talk, they started riffing off each other, and arriving at some strong agreement, despite the seemingly opposite positions of their presentation titles.

image

The day featured an enjoyable  knowledge exchange for the relationship of Scrum to project management. Tomorrow will be day 3, featuring an open space format.

Question: What do you think of the observations of these experts?

Orlando Scrum Gathering Kicks Off With A Bang #sgus

Posted on
3

This week marks the annual North American Scrum Gathering in Orlando. This year’s event promises to be very dynamic, with a track dedicated to project management as well as several Pecha Kucha talks.

Day Zero
But before the festivities even began, Mike Vizdos and Jean Tabaka convened a pre-gathering  retreat for Certified Scrum Trainers/Coaches. Thirty or so of Scrum’s thought leaders spent a full day trading tips and techniques for helping people learn and do Agile Project Management with Scrum.

image

There was much discussion around the correlation between coaching and training. The consensus that, regardless of which certification you hold, you need to do both coaching and training for any successful Agile change initiative.

Day 1 Kickoff
Then yesterday came the big kickoff. Scrum Alliance President, Tom Mellor, welcomed 300 attendees. Like last year, he asked for a show of hands for who was a PMI member / PMP, and a solid 40%-50% responded. He also announced the Scrum Alliance board will feature member-elected slots starting in the second quarter of this year. Then Luke Hohmann briefed everyone on the process the Scrum Alliance used to prioritize the backlog of member needs and requests. The results are yet to be finalized, but it was encouraging to see the Scrum Alliance share how intentional it is being with developing its strategic plan. After these introductions, Jeff Sutherland and Kent Johnson took the stage to talk about Scrum + CMMI. And offered some juicy quotes and tidbits:

  • Regarding role of managers in large scrum: learn to let go of control, motivate improvement, and lead.
  • Some companies are using scrum to manage their cmmi level 3 efforts…with great results
  • Root cause analysis of failures. Is a key source for Scrummaster’s impediment list
  • common benefit of cmmi is rework. Systematic, a CMMI Level 5 agile company moved from 50% of efforts reworked to 6%
  • scrum maps closely to cmmi level 3 when used with agile engineering
  • 50% of Scrum teams do not have working software at the end of
  • “pure scrum” doesn’t make sense and is useless.
  • 20% improvement with scrum is a waste of time you shoul be striving for 10x improvement
  • Self-organization does NOT mean you get to do what you want
  • Don’t misread the agile manifesto to say process has NO value

Day 1 Deep Dive
After the intro sessions, there were several day-long deep-dive sessions to choose from:

  • Dialogue Room & Scrum Clinic hosted by Michael de la Maza and Gerry Kirk
    Project management, How to: Specify Critical Product Quality Requirements -  Tom Gilb and Kai Gilb
  • Software Craftsmanship Workshop – Micah Martin
  • Artful Making Workshop – Lee Devin
  • Coaching the Coaches - Lyssa Adkins
  • The Kanban Exploration – Karl Scotland
  • Coaching Self-Organized Teams - Joseph Pelrine
  • Improv: The Mechanics of Collaboration - Matt Smith
  • Innovation Games® for Scrum Teams - Luke Hohmann

I chose Innovation Games®, and was floored. After only a couple hours, I knew that I would simply have to attend the full 2-day class to get all the golden goodness Luke had to offer.

image

Innovation Games® are facilitation techniques for collecting, organizing, and prioritizing requirements. I continue to be amazed at how little project managers (i.e. people like me) are trained in real product management. I used to think “requirements management” was about enforcing scope with change requests, but now there’s a whole new world I’ve been exposed to. For example, here’s a question every PM should be able to answer: how do you know your requirements are even correct? Yeah, it stumped me too.

It was a fantastic first day, with only more exciting stuff to come tomorrow.

Scrum Is Dead. Long Live Scrum. [Part 2]

Posted on
2

Over the last week or so, Cory Foy and I have been trading posts about the state of the Scrum universe [Click here for Part 1]. In his last entry, he writes with vim and vinegar, and comes to a compelling conclusion: “Get Scrum Working Well in One Industry” BEFORE we “Implement Scrum In [other] Specific Industries”.

That is to say, if the co-founder of Scrum estimates that “75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it”, then what makes us think we’ll do any better by broadening the scope of what we want to do?

If Scrum in I.T., then isn't a cross-industry focus on management premature?

It sounds pretty cut and dry, doesn’t it? Focus on your niche, and don’t overstretch. But there was something about it that left me unsettled. It’s taken me days to digest this, but I think I have some counter-points:

  • First, the 75% failure rate of Scrum is one man’s hunch. When Ken Schwaber says only a quarter of those trying Scrum get what they want from it, that’s based on his own implmentations. Certainly most teams would fail to meet Ken’s very high standards. But what if we instead asked “How many of those who tried Scrum or Agile techniques saw at least some positive improvement?” or “How many teams were in on the whole at least a little bit better off for exploring Scrum?” I bet the answer would be much different. There’s no way I would say a majority of my own clients and trainees meet my standard of a high-performing team”. However, I would say that most are HIGHER performing. The goal is improvement, not perfection. Don’t let your ideal take away from the good that is being done.
  • Second, defining your niche as broad vs. deep is a false dilemma.
    The Scrum Alliance is NOT a company that has to choose between a narrow vertical industry or a very specific generic offering. Rather, it is a formalized body that supports an organic movement to “transform the world of work”. It is a big tent that provides tools and products to equip any one person’s niche within that movement. Whether offering an article for how to interact with a large company PMO, or supporting a local user group consisting mostly of GUI designers, the SA responds to what its members ask for.

    Choosing between breadth-of-impact versus depth-of-impact is a false choice

    The niche for the SA is not a specific depth or a specific breadth of product, it’s this: “helping teams get better using Scrum”. From Tony Robbins to Colin Powell, many people make the world better by having a similarly broad-based niche. Your niche can be both deep and broad, so long as it is still a very narrow deep and a very thin wide. Tony Robbins can tell you get a little bit better as a person (thin & broad), but will mentor only a few people to become amazing as self-help instructors (thin & deep). Colin Powell will help many many people become better leaders (thin & broad), but will advise only the senior-most generals and politicians on how to become chiefs of state (thin & deep).

ABSOLUTELY, Cory is right that the Scrum Alliance has some work to do to become more effective at this mission. The recent leadership drama, churn over the certification exam, and the delayed transparancy are all problems that need to be fixed. Furthermore, he is right to describe the lack of industry-specific guidance as “magic happens here”. You should read his post. However, I do not think the SA’s execution issues point to having the wrong mission.

Scrum Is Dead. Long Live Scrum. [Part 1]

Posted on
12

There has never been a shortage of criticism around the Scrum method for agile project management. However there has been a recent spike in the churn and swirl, and it’s time for some perspective. Specifically this:

The old understanding of the Scrum landscape is dead, and a newer more relevant version is rising in its place.

However, with this jarring change, comes a lot of complaints, confusion, and cults.

1. Complaints over Scrum It’s hip to complain about Scrum. All the kids are doing it, and it makes you feel good. A couple years ago, Jim Shore was among the first cool rebels, saying “Rescuing Scrum teams keeps me in business”. His complaints boiled down to Scrum certifications, which give beginners a false sense of competence, leading to disasters that he has to clean up. The criticisms haven’t changed since then. Just a couple weeks ago, agile co-founder Bob Martin posted his thesis on the shortcomings of Scrum, which offered the same old critiques we’ve heard before. Several people offered their rebuttals, but I doubt that will stop the hen-pecking any time soon. Granted, some of the criticisms are legitimate. But I see very few of these hipsters stepping into the mire to make things better. I am much more impressed by gurus like Ron Jeffries or Alistair Cockburn, who became Scrum trainers because of the complaints, so that they could be a part of the solution. It turns out that Bob Martin and Jim Shore have been contributing to the upcoming Certified Scrum Developer program. This, it seems, is their noble attempt to fixing Scrum’s lack of focus on technical training, which confuses me a little…since they’re still complaining.

2. Confusion over Scrum Over the last week, Mike Cottmeyer has been asking some good hard questions about what Scrum really is:

  • “How can you certify something that doesn’t have a standard body of knowledge around it?”Actually, the official statement of the Scrum method is spelled out in the Scrum Guide. The problem is that it’s too prescriptive, and the ‘experts’ aren’t very good at explaining what that means. For example, I’ve seen several hyper-performing teams that don’t have a burndown chart anywhere. The official body of knowledge would call them non-compliant ‘ScrumButs’, but I would say the burndown is optional. As long as you some kind of empirical visibility into whether they will make your deadlines, you’re okay. Further exacerbating the problem is the exam, which offers a few questions that focus on the letter of the law, rather than the spirit. So, as in any complex field, there are good ScrumMasters and bad ScrumMasters, good PMPs and bad PMPs, good doctors and bad doctors, good lawyers and bad lawyers. When you have a disparity among experts certified in a complex field of many grey areas, then the market is the ultimate decider of who’s got it together. There is a reason why Mike Cohn is the best-selling author on Scrum: his examples offer the pragmatic flexibility the market wants.
  • “How can you certify a developer, when there’s no developer role in Scrum?”. The Scrum Alliance already certifies more than just the official roles in the Scrum method (i.e. practitioner, trainer, coach). A developer certification will be the first introduction of a scrum application role. There is a LOT of dialog happening around the Agile BA, the Agile User Experience Designer, and the Agile Portfolio Manager. But there’s no formal agile method that calls those roles out either. Yes, the market is yearning for practical knowledge on application of agile thinking to specific job descriptions. I get a lot of questions from people asking how to apply scrum if they are a graphic artist, or a tech writer. But, that doesn’t mean Scrum is confused about what it is. Scrum is still the same at its core. I think it’s perfectly reasonable for the stewards of a methodology to offer maturity around how to apply it to a given skillset. imageWhat’s even more ironic about all this is the ongoing complaints. It used to be “Scrum is evil, because it leaves out technical practices.” Now it’s “Scrum is evil, because it wants to promote technical practices.” So which is it?
  • “Shouldn’t Scrum focus only the IT field?” - Software people grumble about the Scrum Alliance’s stated mission to “transform the world of work”. However, I believe we could have the most mature IT department in the world, but still have that IT department reporting into a broken corporate culture. We’re seeing high-quality software evolving the fundamentals of human communication and learning at break-neck speeds, but we still laugh nervously at the sit-coms depicting bad bosses. You mission is your mission. My mission is my mission. You want to create a new set of expectations around what it means to be a software engineer. I want to create a new set of expectations about what it means to be a manager or executive. Scrum fits my mission, and it doesn’t fit your mission, that’s okay. Just don’t tell me my mission is foolish.

3. Cults Recently, Scrum co-founder Ken Schwaber stepped away from his activities at the Scrum Alliance and launched the Scrum.org initiative to focus on the software industry. Yes, there was some disagreement and some hurt feelings about how things played out. Yes, there is some confusion as to the differences and similarities between the two organizations’ products. It’s messy and confusing, and Cory Foy spells out all the sordid drama. Many have been left feeling like they have to pick sides.


But that’s what creative destruction is all about. One guy does something first, the next guy does it better. Another guy holds true to a niche, and another branches out. Then, you have a little consolidation of players and a few products being abandoned, and eventually the landscape settles. Already, the Scrum Alliance points to Scrum.org as the authoritative definition of the Scrum method itself. Furthermore, Schwaber is being featured as a headliner at the upcoming Scrum Alliance Gathering in Orlando. So, some reconciliation and consolidation is happening already. Unfortunately, it’s human nature to gossip about the drama, but that won’t be the ultimate determination of what the market will choose.

That’s my take on things. The old understanding of Scrum is dead. It no longer fits nicely into a the box you want it to be confined to. Instead, there is a newer more mature understanding of Scrum evolving. The Product Owner committee, the skill-specific applications of Scrum, and the transfer of ownership from Ken Schwaber to a democratic community are all examples. Scrum is adapting to real world constraints, in order to become more relevant to the real world.

Scrum is dead. Long live Scrum.

[Read the comments below, and then read Part 2]