I recently spent a full day at a Fortune 500 company consulting their Agile Center of Excellence and later presenting to a larger group of Executives. I actively listened to what they told me about their organization, their successes and struggles with Agile. They asked lots of questions about how I’d done things in past Agile engagements, including Agile at the Enterprise level. All in all, a very rewarding experience.
But it was the topic of scaling Agile that seemed to garner the most interest.
Image credit: tads-usa.com
I think many organizations have been attempting Agile at the Enterprise level for a while now, but maybe not doing it in the most efficient and effective way possible. There’s clearly real opportunity in this area. Overall, companies appear to be doing great on the Project (Team) side, but struggling at the Program and Portfolio level. In order to link our overall strategic vision with projects, and coordinate those projects across teams, we must be effective at this. It’s vital to the success of any organization.
Enter Dean Leffingwell, creator of SAFe (Scaled Agile Framework). His framework and accompanying certification program is all the rage in Agile circles today. I believe folks have been looking for someone to put a formal framework (and catchy tag) to this for a while now. And to Leffingwell’s credit, he has done a good job of that with SAFe. Check it out at http://www.scaledagileframework.com
While Leffingwell labels SAFe as a framework, some of the folks I’ve talked with and various blogs I’ve read see it as more prescriptive (a methodology). And while thorough, some are suggesting it may be a bit too complex.
But maybe that’s what folks want right now; something that tells them exactly what to do, when to do it, who does it, regardless of its complexity. In fact, I see some new teams that approach Scrum like that. Even though it was created as a framework, they treat it like a set of standards and procedures that must be followed to the tee.
So let’s consider how organizations accomplish their goals and reach their strategic vision in an Enterprise. Call it Scaled Agile, or call it Enterprise Agile. I’ll use the latter term for simplicity.
There are three levels necessary to successfully implement Enterprise Agile; the Portfolio, the Program, and the Project.
At the Portfolio management level, we’re deciding if we’re making the right investments that will allow us to realize our strategy and vision. You may have at least one and possibly several Programs within a Portfolio.
At the Program management level, we’re managing resources and deliverables. Our job is to drive the execution of the decisions made by Portfolio Management. This requires we communicate constantly with them, so they’re always aware of any changes (e.g. how dates might be affected.)
At the Project management level, we’re getting the most granular level of work done. Part of our job is also to deliver status to the Program.
In short, all three levels must share information and communicate constantly. What we don’t want to happen is for any of these layers to get silo’d. Enterprise Agile simply won’t work effectively if they do. We need a holistic approach that helps us to deliver to our customers what they want and need. Based on some of my experiences, this is exactly where a lot of organizations fail with Agile.
As for the nuts and bolts details of how to accomplish Enterprise Agile in an Agile software management tool, check out how VersionOne does it. This video walks you through it step by step, simply and elegantly.
How are you scaling Agile in your enterprise? What are your challenges?
They say the best way to learn is sometimes through failure. I couldn’t agree more.
Now you may be thinking, "Yeah, that sounds nice, but my boss doesn’t like failure. And I don’t like getting called on the carpet. The culture in my company doesn’t encourage risk taking. In fact, we get penalized for failing via negative performance reviews."
Welcome to the culture of command and control; management by fear.
Now don’t get me wrong. I agree that we should try to mitigate risk. But on the other hand, we might not come up with that new groundbreaking technology if we never take a chance, step outside our comfort zone every now and then.
Funny thing; agile both mitigates and encourages risk at the same time.
It mitigates by employing short, 2-week timeboxes; by allowing the customer to see what we’ve built for them at the end of those timeboxes; by having team retrospectives, identifying what we do well and where we can improve; and by practicing agile technical practices.
An agile culture encourages risk taking by making clear that we will never win in the long-term by sticking to the status quo. We must take calculated risks and invest in them. R&D isn’t the only place that spends money on crazy ideas. The IT divisions are becoming increasingly important to a company’s success or failure.
As an Agile Coach, I find one of the hardest things to learn is to let the team fail. Watching and waiting is not an easy thing to do. That said, as a Coach, I’m not going to allow them to make an epic failure that would cost the company millions of dollars. But I do want the team to feel comfortable taking chances and using failures as an opportunity to learn.
If you’re overly protective of your team’s failures, they will recover from failure more slowly, learn less, and become weaker as a team. And, as you might expect, the opposite holds true.
And an epic failure at the end of a long cycle (6, 9, 12 months) is frowned upon even more, as it should be. Accordingly, this is the dig on the waterfall approach to developing software. At the end of the 12-month project, we may think we got it all right. We may have even worked double-time at the end to get there. But when the day comes to go live, we discover that what we created doesn’t work like it should, isn’t quite what the customer asked for 12 months ago, or the market has changed -- and this thing we spent so much time creating is no longer valuable.
It’s not uncommon to end up only using 20% of the original requirements list. That’s a pretty large failure risk, if you ask me. Over my 10 years of managing waterfall projects, I’ve had more than a few projects fail in this way. Of course, as the Project Manager, the fingers were usually pointed at me. I loved my job. NOT!
Enter agile development. I made the transition from Project Manager to ScrumMaster very naturally. For some PMs, it’s not a good fit. Hard to shake that command-and-control mentality. But I liked this new and refreshingly realistic way of working and getting stuff done. If we failed in agile, we failed at the 2-week mark, not at 12 months. Simple. Brilliant. The finger pointing ceased. We succeeded or failed as a team. And if we did fail, we got better the next time, or we pivoted and went a different direction. 'Why hadn’t we all been doing this the past 4 decades,' I thought to myself. But that’s another blog topic.
Bill Cosby once said, “The desire to succeed must be greater than the fear of failure.” Ruminate on that.
Is your energy focused on succeeding or failing?
One of the biggest struggles I’ve seen in organizations adopting Agile is in the area of Production Support. Every organization that has a product to support has to manage this. It’s a critical part of the business. There's a lot of responsibility to manage a 24/7 Production environment. The middle of the night calls, working on code you didn’t create. Speediness, precision, reaction time and problem-solving are crucial.
The struggle typically comes in the form of pulling people away from active Scrum teams to make whatever hot fixes are necessary. This is clearly disruptive to the Scrum development team. Oftentimes, a team member is being pulled away to work on something that's very unpredictable. Who knows how long they could be gone from the team; an hour, a day, a week? This disrupts our rhythm and velocity. It makes planning difficult. Team cohesiveness suffers. The person getting yanked to do the Production work usually isn’t too happy either. Context switching makes them less productive. And in the end, we actually get less done!
Alas, we need to get these ongoing high priority bug fixes out the door asap. And we need the ability to re-prioritize any time. We need focus. And we know that 2 week sprints aren’t a good fit.
So how do we combat this? How can we keep our Production environment up to speed, while also allowing our Scrum teams to develop that stuff they’ve committed to getting done for their Product Owner?
My preference, and one that I've seen work well in many organizations, is to create a new Production Support team that works these hot fixes as part of a Kanban effort. The only negative feedback I’ve heard on this is that it seems like punishment to some (think of the Gulag in Northern Syberia). To combat this feeling, we’ve tried cycling folks on and off the team so they don’t burn out. As any good Managers knows, it goes a long way to show your appreciation to this group in some way. Maybe a really nice work environment, new laptops, snacks/drinks, etc. A sincere pat on the back also works wonders. Get creative. Additionally, there may be some folks that don’t fit well in your new highly collaborative team culture. They're very smart folks, but more of the lone wolf variety. This team could be a natural fit for them.
At the end of the day, technical debt is something that will keep us in this death spiral. We want fewer bugs in Production. In order to get out of it, we need to improve our technical practices, our code quality, our testing, our architecture, and our design. It’s hard to make any progress if we keep patching up something that’s not good to begin with. Sometimes it’s just easier in the long run to scrap it and start fresh (I know, that’s a hard pill to swallow).
How do you handle Production Support in your Agile environment?
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?