I am a Java Programmer. I am a User Experience Designer. I am a Quality Assurance Analyst. I am a Business Systems Analyst. I am a Technical Writer. I am a Data Analyst. I am Project Manager. Moreover, I am a Senior level Project Manager, et al.
But in Scrum, our titles are simply 'developers'. We view all team members as peers. It doesn’t matter what your specialty is. If you’re a member of a Scrum team, we call you a ‘developer’.
Wait just a minute… I worked hard to become what I am. I went to school, spent many long grueling hours, years even, perfecting my craft. I have certifications. When someone asks me what I do, I’m proud to tell them I’m a Java Programmer. This is my identity. Now you’re telling me I have the same title as everyone else on the team? Hogwash. I’m better and smarter than the others. I’m a rock star at this company. I make more money, and am more senior. I don’t like this idea of calling everyone a ‘developer’. But I’ll humor you because I know my boss supports Scrum. What I won’t tell you is that this has put a bad taste in my mouth. Scrum…
Identity is a person’s conception or expression of their individuality or group affiliations. And if I’m where I want to be professionally, my title is reflective of that.
Frank: Jim, what do you do for a living?
Jim: I’m a Java Programmer for IBM.
This is a pretty typical answer, wouldn’t you say? Jim identifies with his own personal identity first (Java Programmer), then the group (IBM). I get asked this same question a lot. Depending on who asks me, I may answer differently, but I do the same thing. Even though they only asked what I do, I deliver those goods and then some. I also tell them who I work for. I’m a unique individual, but I’m also a member of a larger team.
This ‘developer’ classification takes a bit of getting used to for folks new to Scrum, so let's take a simple analogy… Think of your teachers in High School. You likely had at least an Algebra teacher, English teacher, Art teacher, P.E teacher, and Biology teacher. Regardless of their specialties, they were all 'teachers'.
In this same way, a ‘developer’ on a Scrum team may specialize in data analysis, design, testing, technical writing, and yes, even programming.
So why does Scrum do this? Can’t we just let folks keep their old titles. They’re descriptive, everyone is used to them, and they’re a source of pride in many cases. Why upset the apple cart? In short, to drive cross functional, self-organizing teams, and create an ‘All for one and one for all’ atmosphere. When someone needs help with a task that isn’t part of my Personnel defined job title, it shouldn’t matter. If I can help them, I will. And if I can’t, I’ll learn, because there may be a next time. This may sound trite, but at the end of the day, we’re all in the same boat. We will succeed or fail as a team. Not as a bunch of individuals.
We usually do let folks keep their official, non-Agile titles, however. Personnel departments still use them as a way to distinguish pay levels and seniority. They normally have each title documented with a long list of requirements, responsibilities and salary scales. But guess what? We can do the same thing with the three roles in Agile (Product Owner, Scrum Master, and Developer).
Now I must come clean; occasionally I use the more specific ‘specialist’ title for folks, like programmer, architect, DBA, QA, etc. for referring to developers for the sake of precision, but if I don't catch myself, the developers on the team usually do for me. Sometimes I’m not sure if it’s genuine, or a smartass thing. Regardless, they do understand that while we recognize our differences, we’re all members of the same team. And we’re all ‘developers’.
What is your experience with Scrum teams and the ‘developer’ moniker?
the state or quality of being dedicated to a cause, activity, etc..
“the company’s commitment to quality”
The roles in Scrum are simple. The Product Owner owns the vision, product backlog, and ensures their needs are clearly communicated to the team. The Scrum Master ensures the team is following the Scrum framework and helping to remove impediments along the way. And the Team is responsible for getting the work done they agreed to.
But we know in reality it can be much more complicated than this. Before I start railing on Product Owners, let me be clear. I’ve seen lots of truly great ones. They are highly engaged with the team, customer, and stakeholders, are superb communicators, and make themselves available whenever needed. In short, they’re committed to the project and the team.
Alas, I do have empathy for Product Owners, as I have been one myself on several occasions. Sometimes we simply don’t have the time or commitment level that’s necessary. Product Owners have time constraints, likely juggling multiple duties and projects. My experience has shown that Product Owners are usually people with high levels of business knowledge and therefore in high demand throughout the company. It’s hard for them to say no when a V.P. calls up and asks them to work on a special project at moments notice. Something’s gotta give. And unfortunately, it’s the Scrum project that suffers. The root cause in this example could be several things; maybe the Product Owner wants to please them and therefore doesn’t tell them their team is counting on them on the Scrum project. Or it could be that the Product Owner does communicate this to the V.P., but the V.P. doesn’t fully understand the Product Owner role, or isn’t committed to the Agile adoption and transformation effort underway in their organization. Of course, this is all assuming the Product Owners themselves have been trained on their new roles in Scrum, fully understand the expectations, and the resulting consequences if they’re not engaged and available every step along the way. I’ve seen all three scenarios. If the Product Owners aren’t fully aware of their new role, there is clearly an opportunity for the Agile Coach or Trainer to take action and get them up to speed. It’s funny (and kinda sad) how many times I’ve found this to be the case on new Scrum teams. One would kinda assume this person was trained on their new role and expectations before starting up a new Scrum project.
But let’s get real. I’ve seen many occasions where Product Owners simply choose to partially or fully ignore their new role. If this is the case, there are a few options. One is to assign a Product Owner Proxy, who can make speak for and make all decisions on behalf of the Product Owner. In this case, make sure the Product Owner fully understands this Proxy role, because the same thing can happen if they don’t. Misunderstandings, disagreements, re-work, bugs, finger pointing, schedule risks, etc. Not to mention the Proxy can end up feeling unappreciated, dejected, and lose respect for the Product Owner and from the team.
The other two options are more nuclear. Simply stop the project and wait for them to be available. Make it clear why you’re doing so. If you move forward without their input, be sure to identify and communicate the risk; mainly building something that either won’t be used, or is going in the wrong direction. Or tell them that they’re not cutting the mustard as a Product Owner and you’d like to request someone who can commit to the team. These are difficult conversations for sure, but sometimes necessary.
And what about the Scrum Master? I’ve seen these folks end up taking on a heavier load due to decreased Product Owner involvement as well. Many times they end up making decisions that should be made by the Product Owner. Sometimes they make the right call and help to move the project forward, other times they don’t, and end up getting burned. This is another case where a Proxy should be selected. But reality has shown me that the Scrum Master often gets this thrown on top of their already heavy workload.
Then there’s the Scrum team members. How do they know they’re building the right thing? They may have to start making assumptions on what to build next, or what the acceptance criteria is for a certain story. What if they’re wrong? Finger pointing, re-work, bugs, schedule risk, dependencies on other projects or releases, etc.
If you’re a Product Owner on a Scrum project, are you fully committed? Do you understand your new role and the expectations? If you can’t be committed, what are you doing about it?
It’s one seemingly simple word repeated four times in the Manifesto for Agile Software Development http://www.agilemanifesto.org
Experience has shown me that many folks either get hung up on or overlook the meaning of this one little word, sometimes leading to a fundamental misunderstanding of the entire Agile Manifesto.
In fact, there’s specific clarification on this within the Agile Manifesto, as follows:
But what does that really mean? How much more should we value the items on the left? A 70/30 split? 60/40? How can we even measure that? Should we?
In this blog post, I’m going to concentrate on the first value statement in the Agile Manifesto...
Certain tools contain definite advantages, particularly if you’re rolling out an Agile adoption and transformation effort across your organization. There’s the Agile software management tool, the various Agile engineering and development tools, the bug tracking tools, and the automated testing tools, just to name a few.
I’m sometimes asked the question, “With the Agile software management tools becoming more and more prevalent in organizations, are we getting away from the importance on ?
I think it depends on the organization, and even the uniqueness of individual teams. It doesn’t have to be some predetermined division between the two. Simply trust that your organization and teams will determine what that right mix is. In typical Agile fashion, it will likely change, as we inspect, adapt and become more mature along the way. If teams aren’t collaborating well with one another, a good Agile Coach or experienced Scrum Master can help drive these behaviors.
If you’re like many organizations these days, in the midst of an Agile adoption and transformation effort, you’re likely thinking about how to scale, how you’ll handle remote work / off-shore development, storing project data safely and securely, reporting metrics, visibility, et al. These thoughts typically lead to discussions around acquiring an Agile software management tool that can provide you with that ‘one stop shop’. And as you might imagine, most Agile software management tools follow your typical Agile/Scrum process (Product Planning, Release Planning, Sprint Planning, Sprint Tracking, Sprint Review).
But just because we’ve acquired this wonderful new Agile management tool that stores all our stuff in one place, provides visibility, metrics, etc. doesn’t mean we can now go back to ‘cube farmville’ and put on our headphones all day long. We should be interacting with one another, collaborating on stuff, ironing out details, confirming understandings, asking questions, going to lunch, getting to know each other better, developing trust and bonds. Face to face interaction. In this new Agile world we live in, producing software requires us to be more social than we may have been in the past. And that’s not something that’s going away. The folks that got into IT specifically because they didn’t want to deal with people may be in trouble. Yes, we all still need our quiet/focus time. That’s what focus spaces are for. Most companies recognize this and in addition to providing small focus spaces outside the team room, are issuing laptops or tablets now, and not desktops. Mobility provides the opportunity to get away and focus when necessary. Ironically, it also provides greater opportunity for collaboration.
One of the best and simplest examples I can think of in terms of successfully marrying up these values (‘Individuals and Interactions’ with ‘Processes and Tools‘) is the Daily Stand Up Meeting. The Scrum Master might display the Team’s active Sprint on a wall/screen using a projector plugged into a laptop running VersionOne (or some other Agile software management tool). Along with the Sprint backlog items and tasks, the team can review the Sprint Burndown chart and the Cumulative Flow as it stands each day. This common project visibility via the tool, along with the process of meeting each day for a DSU helps to drive discussions and collaborative meetings, helping you to plan, track and advance as you go; empiricism - one of the main concepts of Agile methodologies. Additionally, as a result of utilizing both values, there are no real surprises any more. The risks, issues and impediments are being addressed daily with the team, and are transparent in the tool and as part of the process. If folks know what these issues are, they’re more likely to help you remove them; yet another good thing.
By the way, did you catch the change in the first sentence of the previous paragraph? I even italicized it. Used the word 'with' instead of 'over'. Is that wrong? Does that change the way you think about this value?
If you’ve found yourself in an airport recently, your patience, like mine has probably been put to the test.
Start out with satellite parking, riding the shuttle bus, checking bags, TSA security, flight delays, gate changes. Once you manage to get on the plane, it becomes a mad rush for overhead bin space. Turbulence, the smell, sitting on the runway for extended periods of time without movement, screaming babies; the list goes on. And would someone please explain to me why we have not yet figured out a better way of getting people on/off the plane? Only one door to enter/exit; seriously? I say, open that hatch in the middle and let us slide down the yellow inflatable thingy for cryin’ out loud. Note: there are 8 exits on a 737. But I digress…
At the end of the day, I have to remind myself that this will play itself out. Being difficult with a ticket agent or stewardess isn’t going to make a delay any better, and probably worse. I have to trust that behind the scenes, they’re doing their best to resolve the situation.
Occasionally, I will ask questions, and/or make what I believe to be helpful/friendly suggestions. But at some point, I come to realize it’s just wasting my time and theirs. The people on that team are the best ones to figure it out, and they’ll let me know when they do. They are professionals, and I need to trust them, respect their skills and abilities, and be patient.
This leads me to something I’ve seen on a lot of new Agile teams. In my experience, many middle managers seem to have a hard time letting go of the controls. They still feel the need to intervene. Afterall, they’ve been micromanaging for years, possibly decades, so breaking these practices is tough. If you’re a middle manager that’s part of an Agile adoption and transformation effort, you’ve probably been trained on the importance of giving more authority and power over to your team. But in the back of your mind, you’re not sure they can handle it, so you find yourself continuing to micromanage. You continue to keep close tabs and control the team and their individual actions. You make most of the decisions, but you keep telling yourself this is only short-term, until you trust that everyone is doing it the way you would like them to.
Your aim may be true, but you’re effectively preventing your team from developing into a self-managing, self-organizing team. As a result, they continue to look to you for direction, or for the authority to do something they could on their own. You, the middle manager, are trapped. So you carry on making the decisions, all the while questioning why your Agile team isn’t as responsible as you. A vicious cycle.
I’ve seen this snare over and over again. The notion that ‘my team just isn’t ready’ is one of the biggest hindrances to enablement in organizations.
But let’s be honest here. Many of the folks on that new Agile team probably aren’t ready, at least initially. Even with that truth or assumption, as a middle manager, I cannot keep adopting the ‘if I want something done, I’ll do it myself’ defiance.
Being able to take that leap of faith, to trust, to delegate, to be patient, is really an investment you make in other people. It will probably take a while to get a good ROI on my new Agile team. They may struggle out of the gate. Occasional hiccups are OK. We need to think long term here.
Trust, delegate, give up the reigns, and don’t hover. Allow your teams to self-organize, self-manage, and give them the opportunity to learn from mistakes they make. And be ready to help them out when needed. Your role has changed in the Agile world. Embrace it. You’re now an impediment remover and success enabler, not a helicopter boss.
Are you practicing your patience? What are some of your struggles?
“Too many opinions I don’t care about”
I was surprised recently to hear from a few of the ‘younger’ students in an Agile class I teach tell me they don’t use Twitter. Surely most (if not all) young, tech-savvy folks that work in IT would use this popular social media app, I thought to myself. However, a non-scientific, informal survey I conducted (show of hands) held over the past few months in these Agile classes has shown this not to be the case. Believe it or not, there are many middle aged and older folks who are savvy in the ways of social media as well.
So I then asked how many folks used Facebook. Nearly everyone raised their hand to this question. Interesting. So what’s the difference? Why would they use Facebook and not use Twitter? Several of the more outspoken ones told me it was because Twitter was filled with ‘too many opinions I don’t care about’. And both old and young alike said it’s ‘information overload’. They simply don’t have the time to keep up with all the social media stuff.
I have to admit that I got burned out in the past on social media too. Facebook had lost its luster for me. And I didn’t see a ton of difference (at least in the way I used it) between Facebook and Twitter, so I didn’t even bother with the little blue bird. I used LinkedIn, more or less, as an online resume’. Other community sites I had been active on started to become bitch sessions and seemed to be filled with folks who either didn’t know what they were talking about, or were just downright irritating or rude. I couldn’t take much more. So I deleted my Facebook account, stopped posting to the community sites I had set as favorites, and immersed myself in work and family. And I must admit, it was good for the soul.
But I soon began feeling ‘out of touch’. I started hearing about new developments in my industry later than I would like. Reading news on the web just wasn’t cutting it. So I came back; this time in a more ‘manageable’ way for me. I started with utilizing most of the features on LinkedIn (the Facebook for professionals). Things like reading what other thought leaders were saying, connecting with and following people, companies, and influencers. It’s now one of my favorite social media sites out there because it serves so many purposes. I found it useful to set aside some time each day for this. In my case, it was before I logged off for the day.
I also started blogging more. Originally, I had a pretty basic WordPress blog and posted to it intermittently. Only a couple of my friends ever looked at it. I did a poor job of promoting it, and an even poorer job keeping the content fresh.
So I decided to set up my own website (www.agilecaffeine.com). I set an initial goal of one blog post per week and have done pretty well sticking to it. There’s just something cool about having your own unique URL. A pride of ownership thing, I guess. For me, blogging is a great way of bringing out my introspective side. And it’s fun too. I try not to get too ‘white paper’ish’ about it; just write like I think and talk.
Twitter seemed to be a good avenue to share my ramblings and interact with folks who were interested in the same stuff I was. So I started following people whose opinions I respected and wanted to read about (sorry Ashton Kutcher). The key here is to be selective in who you follow. Believe it or not, recently, a number of people have even begun following me.
At the end of the day, I’ve learned that besides being passionate about my craft, I also need to make the commitment to be more socially engaged. And this isn’t just online.
A few concrete examples…
· I utilized ‘Meetup’ to join with the ‘Limited WIP Society’. We meet once a month to talk, play games, eat pizza, and learn new stuff together.
· I created, led and promoted Agile Communities of Practice and Communities of Interest at client sites. These are great because they provide a forum for folks to engage with one another, hash out problems, share, help and learn.
· I’m making a point to be more active in my local chapter of PMI (Project Management Institute). But I must admit, the last time I attended one of these sessions was about 6 months ago. At that time, I presented to an audience of about 150 people on the topic of ‘Writing Effective User Stories’, and had no idea of the keen interest until about 15 minutes before I walked in. Downing a couple of Stella’s at the hotel bar helped to erase my anxieties.
Are you being social? What are some of your frustrations? How have you adjusted?
Let’s talk about that last value a bit more… Courage.
What does that really mean? How can someone in IT be courageous? That’s just for folks in the military or firefighters or police officers, you might say.
Not so, I say.
A few scenarios might help.
Scenario 1 - I’m the Product Owner for a mission critical Agile project. The CEO of the company comes directly to me and says he wants the team to add another feature into our current Sprint. Says he needs it ‘ASAP’. This feature is useful and needed. It makes sense to do it, but it’s not a small demand. The team is making good progress on the current Sprint and only has 4 more work days before they deliver the agreed upon functionality for the 2-week Sprint. Would you simply say ‘Yes’ because he’s the CEO, or would you delve a bit deeper into the current status of the project/sprint and the priority of your Product & Release Backlogs, explaining to him that stopping a Sprint in progress could have larger impacts, and what those might be? Clearly, this takes courage.
Scenario 2 - I’m the Manager of the newly created Agile PMO.
I report directly to the VP of IT. She’s a reports junkie; likes to see a lot
of em’ and at many different levels. Also likes to have me deliver these reports
verbally and via email to several different groups of folks in the organization. Changes her mind a lot on what she wants to see too. I spend an inordinate
amount of time doing this reporting and delivery, which I believe should not take up this much of my time every week. I have many other important items to
tend to, as the organization is in the midst of an Agile adoption and
transformation effort. Do I have the courage to set up a conversation with her
and explore her motives, exploring new ways of disseminating information,
explaining the impacts this current situation is having on my many other
demands? This takes courage.
Scenario 3 - I’m a Team Member on an Agile team. My forte’ is writing Java code. But I can do almost anything, or at least am willing to try/learn. If I finish up the tasks I signed up for in the current Sprint, I ask around if anyone on the team needs help. If not, I get coffee, or give shoulder massages. But there’s one individual on the team that doesn’t have the same ‘All for one, one for all’ attitude that the rest of us do. Oftentimes, during the Daily Stand Up meeting, he’ll report that he’s ‘got nothing’, and looks to move on to the next person to answer their 3 questions. He doesn’t ask if he can help or learn how to do something; doesn’t appear to be a team player. Do I have the courage to go to him and ask what’s wrong, or how I can help? And if that doesn’t work, do I have the courage to suggest that we remove him from the team?
Here are a few more questions of courage to ask yourself...
Do I have the courage to try something completely outside of my comfort level?
Do I have the courage to be completely open?
Do I have the courage to throw away bad code I created, even late in development?
Do I have the courage to allow my direct reports to ‘self-organize’?
Do I have the courage to become less command and control and more collaborative?
Do I have the courage to give up my cubicle, and a bit of my privacy?
Do I have the courage to say I’m scared how this new way of working will impact me?
Do I have the courage to ask for help from someone junior to me?
What are some of the more courageous things you’ve done in IT, and what impact did they have?
OK, I'll admit it. I love Zombie movies. And yes, I know Zombies aren't real.
Guess it's the not so subtle mix of violence and humor that appeals to my sophomoric tendencies.
One of my Agile students mentioned he recently saw the movie 'Abraham Lincoln vs. Zombies'. In that moment, there was an instant bond and we became fast friends, recounting some of our favorite scenes over lunch.
If you haven't seen this one yet, I recommend cancelling any plans you may have had for tonight and doing so straight away. But be warned, this isn't the stuff of Steven Spielberg; it's a B-movie that went straight to video.
You're probably saying, "Enough about Zombies and your favorite movies already. How does this relate to Agile?"
Well, here it goes... I lovingly refer to people in my own personal clan that spend way too much time on their smart phones as 'Phone Zombies'. They seem 'severed' from the real world directly in front of them. Texting, apps, social media, news, weather, games, music, video, and the entire world wide web at their fingertips. Oh yeah, they tend to talk a lot on it too, as it is a phone afterall (although it still seems more like a walkie talkie to me).
What suffers with the 'Phone Zombie' is the face to face communication and personal interaction. When I'm sitting with a Phone Zombie, I'm thinking "Here we are, smack dab in front of one another, and you're more interested in texting, updating your social media page, or playing a game than having a real conversation." I see this a lot at restaurants. And before we get all high and mighty as the 'adults' here, this isn't just something teenagers do. We adults are just as guilty, and are largely the ones that make up the teams that develop software. When I see this behavior on an Agile team, I consider it a 'smell'. And as an Agile Coach, it disturbs me when the smartphone (or any other device or tool for that matter) impedes effective communication on a team.
There are so many ways to lose ourselves into this little device we carry with us every waking minute of the day. It's personal. It's cool. It's interesting. It's fun. It's addictive. And it can, in fact, serve as a truly great communication tool.
But when I'm on the clock, I try to use it to check only for urgent items that come across the wire. If it's not an emergency (a tricky definition, I know), I try not to get distracted, although we all know that's easier said than done. If I'm delivering a training course, for example, I might do a quick check of my emails over a break, and if I have time, respond to the more urgent ones in short order. Otherwise, I try to keep my attention and focus on the goal for that day.
And that's the real issue here; attention, engagement, and focus.
While clearly one of the greatest inventions in our lifetime, I believe the smartphone has become, for some, an impediment to effective communication and getting work done. By the way, I'm still waiting for someone to raise this as such in a daily stand up meeting.
The Principles behind the Agile Manifesto tell us that:
Business people and developers must work together daily throughout a project.
We build projects around motivated individuals, giving them the environment and support they need, and trust to get the job done.
And the most efficient and effective method of conveying information to and within a development team is face to face conversation.
Clearly, this all requires our attention, engagement, and focus.
I suggest letting the team decide what's the best use of mobile technology. This can be easily spelled out in the 'Team Rules' you create when starting any project. Accordingly, I do this at the beginning of all my Agile training classes, with the help of the students. I believe most folks appreciate it, as it acts as a reminder of the importance of what we're talking about and gives them a certain 'permission' to focus on the project or task at hand. For example, the team may collectively decide that Twitter is a good tool and should be used to share with their followers what a great Agile instructor they have today, or something groundbreaking they just learned about writing good acceptance criteria. The only warning I would put out is that while someone may be tweeting that important message via their iPhone, they could also be missing something crucial to the conversation going on right in front of them. I'll leave the topics of 'context switching' and 'active listening' for another blog post, but they definitely apply here.
I'd like to think that if President Lincoln were alive today (he'd be 204), and had some time on his hands after a long day of Zombie slaying to chillax with his iPhone, he might think back to something he said in a message to Congress on December 1st, 1862...
"The dogmas of the quiet past, are inadequate to the story present. The occasion is piled high with difficulty, and we must rise with the occasion. As our case is new, so we must think anew, and act anew."
In other words... inspect and adapt.
How has the smartphone affected your attention, engagement and focus?