What I really enjoy about being part of the Agile community is open communication and willingness my colleagues have to learning and self-improvement.
I’ve been fortunate enough to interact with some wonderfully brilliant people and a keen observation I’ve taken away is how these folks give feedback to fellow colleagues. The flip side is that when it comes to a manager/employee relationship, very few managers I’ve worked with have this unique skill. I’m quite sure there are some great books on how to give effective feedback (actually, please add some to the comments…I’d love to read some) but I’ve been on the receiving side of enough generic “great job!” comments to know what people truly find appreciative when receiving recognition.
While praise has it’s place, there is no substitute to providing concrete examples of WHY you are appreciative of someone else’s efforts. When I give feedback to team members, employees or direct superiors I make sure to provide them with specific examples of why I appreciate them. A recent example was feedback I gave to a co-worker who is not part of the team I’m working with. This person provided support to our team and also willingly participated in a couple of estimation and planning sessions because the team needed his help. I made sure to state my appreciation that, although he wasn’t part of the team, the team experienced success because of his help at key points in project.
Another side effect of being specific is that your feedback will be more honest and the receiver will be more appreciative because they will know you aren’t just blowing smoke.
Recently I had a brief messenger chat with a former co-worker that they determined they were actually using Scrum-ban instead of Kanban. The timing of this chat coincided when I seemed to be coming across a multitude of discussions about what is/is not in Scrum, what is/is not Kanban and so on.
My initial response was “is what you are doing working?“. Her response was, “yes“.
My response, of course, then was “so why does it matter?”
I do understand the desire to have these processes defined but I’ve never much been a fan of labeling. Being “Agile” isn’t about using Scrum, Kanban, Lean or any other tool/process, it’s about being dedicated to empirical processes that work within the context. I also understand the dangers of ”Agile” being tarnished by misused practices but by and large solving problems and rejecting the status quo are what really matters at the end of the day.
As an example, a few months ago a team member who was recently kicked off the team BY the team decided it was worth his time to prove a point by finding a page in Ken Schwaber’s book that mentions it’s not a rule for the team to stand-up at the daily scrum. My reply was pretty simple in the sense that I never said it was a rule. I explained to the team why it’s a good idea to stand-up and the team decided they wanted to sit, so they now sit. (results of our daily ’sitdown’ here).
Is sitting at the stand-up a Scrum smell? Probably. I don’t care though. The team gets more value out of sitting.
Before I knew what “Agile” was, common sense would dictate that if something isn’t working, find a better way of doing it by trying something new. I believe that’s much more valuable than worrying about what label you put on it.
I’ve been compiling notes over the years with thoughts and ideas about how I could contribute to the Agile community and try to give back just a small slice compared to what I’ve taken from it.
I decided recently to write a white-paper that describes the experience of the success of a pilot Agile team within a large enterprise organization. What I hope to accomplish by writing this are:
- show that we are “breaking” some of the rules, but are experiencing success
- show the challenges large organizations have adopting Agile
- show the mistakes I made, the ramifications and how we forged ahead
- show that motivation is the most important factor in Agile adoption
How I’m going to structure the white-paper:
- Introduction: who I am, context around why I took the approach I did and context around the organization. The company name, projects and people names will be fictitious but the tactics, results and experiences will be real.
- Iteration by iteration: Starting at iteration zero and moving through our 6 iterations for 1 release I’ll show what our iterations looked like, what activities we did, how we co-ordinated with other groups, team frustrations and successes.
- Summary of what we learned: How the team felt moving from old status quo to new status quo and why they would never go back to “the old way”. This will also include what the team is planning to do for the next release in an attempt to show that despite the success, they recognize they are “not done” implementing Agile and want to get better.
- Reflection: What I learned, what I would differently next time.
- When will it be done? End of December
- How many pages? 10 pages tops, I would like to keep it concise
This is my first white-paper, I’m excited and nervous all at the same time, but this is taking me out of my comfort zone and it is quite challenging. I welcome your input and feedback regarding what you would hope to get from reading this white-paper when it’s finished.
One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?” After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.”
A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“ There seems to be a clear delineation between these 2 camps.
I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.
The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile. Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.
Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.
So underneath the skepticism and FUD, what’s the REAL problem? What are people afraid of? Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:
1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”
2) Agile won’t work here, everybody works on multiple projects at the same time.
3) Management tells us we HAVE TO launch with all these features on this date.
Hmm. So what do we do? Where’s the Agile checklist that allows us to fix these problems? I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality. In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done. The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.
I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”
While our topics do differ, the underlying tone is the same. Organizations needs to understand what being Agile is. They need to look to the manifesto, not to the Nokia Scrum test or a checklist. They need to un-learn what has been instilled through so many years of the command and control approach.
AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about? what are your challenges? how can the knowledge and tools I have solve your problems”
Lately that approach is working much better and I find people who want help are more likely to accept help.
I attended the Rally webinar about Keys to Successful Release Planning and heard a great comment from the presenter:
“Focus on delivering software, not the plan.”
Think about that for a minute, it’s ok, I’ll wait.
<insert jeopardy music here>
One of the myths of Agile is that Agile teams don’t plan. Agile teams focus on ‘planning‘, not ‘the plan‘, there’s a difference. Let’s face it, the software development industry moves quickly and for the lack of a better phrase it would just be completely nuts to plan out exactly what we will deliver for all of next year. Sure we’ll have a loose plan for what we want to deliver based on what the company strategy is, but are we going to follow that plan into the ground or adjust to new information? Remember, the Manifesto says we value responding to change over following a plan.
So what’s good about a plan? Everybody loves a plan. Plans are what keep people accountable, plans are what make us comfortable, plans help us feel secure. Once you have a plan, you have set expectations.
So what’s not-so-good about a plan? Once you have a plan, change is difficult due to the perceived chaos change introduces. Once expectations are set, traditionally changes aren’t effectively communicated to all those who should know about it. Plans can be used to place blame when things don’t go according to the plan.
At the end of the day we are delivering software, not a plan. In the end when plans change and chaos ensues, the issue isn’t the plan, it’s communication.
Case in point, in our iteration 6 demo one of our stakeholders asked “I thought you were doing XYZ?” Was it the stakeholders fault? Nope. Was it the outdated roadmap the entire company was looking at? Nope, ok, maybe partially. It was a communication problem.
We had failed to effectively communicate to all of our stakeholders the change to the plan. Sure this change happened 3 months ago and sure this particular stakeholder hadn’t come to any previous demo but once this stakeholder had the plan in his hands 3 months ago, his expectation was come hell or high water, we will deliver the plan.
This creates a vicious cycle, especially in organizations that lack trust. If the team doesn’t deliver the plan, the business instinctively responds with more process and more control. Obviously the team can’t be trusted if they can’t deliver on this simple plan we agreed to right? People, especially teams, become deflated, morale sinks and people co-operate less for the fear of the ramifications of the decision to change the plan. Another nasty side-effect is the battles about scope-creep. We become so focused on arguing about what’s in-scope and what’s out-of-scope we lose sight of the fact we’re delivering software.
So how do we get out of this oscillating cycle? First of all, communicate better. Help the business, or folks having difficulties adjusting to Agile, understand why Agile teams plan the way they do. Listen to their concerns about why they want a committed roadmap for the next 3 years. People are often resistant to change but it’s important to not confuse their response with resistance. There is always an underlying reason for why people respond the way they do, keep the communication open and move forward. Of course you won’t always agree, but listening to others concerns is a great place to start.