Once upon a time, in a land not too far away, there lived a young man with a head full of dreams.
Every night he would fall asleep and tour castles in the air and see the world on one long magic carpet ride.
Every morning he would wake up, but instead of feeling refreshed, he felt sad. Sad that his dreams stayed only in his head while the carpet in his living room grew dustier by the day.
Then just before the young man’s wheeze developed into a dust allergy, he came across a rusty looking lamp at his local charity shop.
Intrigued by what the lamp would look like after a clean, he gave it a good rub.
And that’s the moment when everything changed.
The young man discovered the genie’s promise of three wishes was no more than a myth, one that the genie had herself made up to stop greedy people from wanting more without taking the time to figure out what they really needed.
And it was a long time before the young man made his first wish for he didn’t want to wish his life away.
And so it was and always will be that everything we dream of begins with a wish.
This article is the second in a series about Susan Evans’ journey from an internal agile coach to an external agile coach. In this part, Susan will cover how she used the agile principle of reflecting on effectiveness and adjusting accordingly by making changes for the better.
[Back to Part 1: “99 Problems But a Coach Ain’t One”]
I strongly believe that if there’s anything in my life that I’m unhappy about, it is only up to me to do something about it. So when I found myself considering a complete career change, I knew it was time to inspect the situation and see what needed to be changed. As hard as it was for me to admit, I found that, as the internal agile coach, I was no longer being heard and, therefore, no longer making a difference.
My confidence was shaken until I elicited feedback from the development teams and discovered that they valued my involvement, but they felt that the executives didn’t agree. In fact, they felt the executives were good at ‘talking agile’ but not good at ‘living agile,’ and no matter what I said or did, the culture beyond the development teams would never truly embrace agile.
That was a very sad day… I helped guide agile teams that were growing, shrinking, shuffling, international, self-managed, and completely brand new with an ever-changing process that evolved to fit the situation. Yet, executives still wanted ‘one throat to choke’ instead of understanding that a self-managed team either succeeds or fails together, not due to a command-and-control manager.
I knew it was time for me to do something about it. So I proposed a solution to the CTO, who was my boss at the time. To make a difference again, I needed to be empowered to influence the culture, which meant that I needed to be a peer with the executives as a Director of an Agile PMO. Unfortunately, he was not interested in an Agile PMO Director so this solution was not available to me. I knew that the environment that the CTO would foster and support was not one in which I would thrive and, therefore, it was my time to evolve and move on to a new opportunity. I asked myself, “What do I do now? In what kind of company and industry do I want to work? What will make me happy?”
To help provide focus and know my priorities, I wrote a simple user story with acceptance criteria:
“As Susan Evans, I want to change jobs so that I enjoy working again.”
Job Satisfaction Acceptance Criteria:
- To make a difference and help people and organizations be happier and more productive and, therefore, proud of my work.
- To respect the leaders of the company I work for in their ability to grow the company and do the right things for their customers. I wanted to work hard to make money for my executives.
- Work for an agile organization… I CANNOT go back to the “dark side!”
- Work for an established and stable medium-sized company where I can work with, and get exposure to, many departments.
- The culture of the company must be causal with attire and work hours, and strive to have happy employees with fun activities during and after hours. I want to feel a part of a hardworking family.
- I want to be challenged and provided the opportunity to learn and grow my skills.
- I want a supportive manager who will trust me to do my job to the best of my ability and provide guidance when necessary.
As Peter Saddington said during a speaking engagement at a Scrum Meetup in Atlanta, life is too short to hate your job. So, I challenge you to write down and prioritize your acceptance criteria for job satisfaction and assess how you’re doing.
Don’t miss my wrap-up (Part 3) of this series coming soon, where I will discuss my experiences as an external agile coach.
Back to Part 1: “99 Problems But a Coach Ain’t One”
Just finished reading The Practitioner's Guide to Product Management by Jock Busuttil and was pleased to be listed as a source for further reading. We hope you'll enjoy our blog!
I’ve been talking to people in the halls about what they learned about goals from last year, and what they are going to do differently this year. We’ve had chats about New Years Resolutions, habits, goals, and big dreams. (My theme is Dream Big for 2015.)
Here are a few of the insights that I’ve been sharing with people that really seems to create a lot clarity:
- Dream big first, then create your goals. Too many people start with goals, but miss the dream that holds everything together. The dream is the backdrop and it needs to inspire you and pull your forward. Your dream needs to be actionable and believable, and it needs to reflect your passion and your purpose.
- There are three types of actions: habits, goals, and inspired actions. Habits can help support our goals and reach our dreams. Goals are really the above and beyond that we set our sights on and help us funnel and focus our energy to reach meaningful milestones. They take deliberate focus and intent. You don’t randomly learn to play the violin with skill. It takes goals. Inspired actions are the flashes of insight and moments of brilliance.
- People mess up by focusing on goals, but not having any habits that support them. For example, if I have an extreme fitness goal, but I have the ice-cream habit, I might not reach my goals. Or, if I want to be an early bird, but I have the party-all-night long, or a I’m a late-night reader, that might not work out so well.
- People mess up on their habits when they have no goals. They might inch their way forward, but they can easily spend an entire year, and not actually have anything significant or meaningful for themselves, because they never took the chance to dream big, or set a goal they cared about. So while they’ve made progress, they didn’t make any real pop. Their life was slow and steady. In some cases, this is great, if all they wanted. But I also know people that feel like they wasted the year, because they didn’t do what they knew they were capable of, or wanted to achieve.
- People can build habits that help them reach new goals. Some people I knew have built fantastic habits. They put a strong foundation in place that helps them reach for more. They grow better, faster, stronger, and more powerful. In my own experience, I had some extreme fitness goals, but I started with a few healthy habits. My best one is wake up, work out. I just do it. I do a 30 minute workout. I don’t have to think about it, it’s just part of my day like brushing my teeth. Since it’s a habit, I keep doing it, so I get better over time. When I first started the workout, I sucked. I repeated the same workout three times, but by the third time, I was on fire. And, since it’s a habit, it’s there for me, as a staple in my day, and, in reality, the most empowering part of my day. It boosts me and gives me energy that makes everything else in my day, way easier, much easier to deal with, and I can do things in half the time, or in some cases 10X.
Maybe the most important insight is that while you don’t need goals to make your habits effective, it’s really easy to spend a year, and then wonder where the year went, without the meaningful milestones to look back on. That said, I’ve had a few years, where I simply focused on habits without specific goals, but I always had a vision for a better me, or a better future in mind (more like a direction than a destination.)
As I’ve taken friends and colleagues through some of my learnings over the holidays, regarding habits, dreams, and goals, I’ve had a few people say that I should put it all together and share it, since it might help more people add some clarity to setting and achieving their goals.
Here it is:
Enjoy, and Dream Big for 2015.
I uploaded my first video to YouTube about a fundamental coaching model. I made the video to support my submission for the 2015 Keep Austin Agile conference. The organizers wisely required a video this year as part of the submission process - A great idea to get a sense of who they intend to invite to speak at their event.
This 9 minute video provides a foundation for new Agile coaches and Scrum Masters to sort through everything going on in their environment to get to action and reflection.
Thanks to my friend and fellow coach Shawn Lowe for helping me shoot this informal video. As always I would appreciate your feedback.
Happy New Year! We hope that 2015 started great for you. To kick off what we expect to be more frequent blogging, this post describes what we believe about Agile. I'm motivated to write this for two reasons - to explicitly state our point of view and to prepare for a Certified ScrumMaster class that I'm teaching this week.
Agile is four values and twelve principles found on the Agile Manifesto home page and on the Principles behind the Agile Manifesto page. That's it. We believe that if an organization of people works together in a way that is aligned to these values and principles that the organization is Agile. We approach all of our teaching, coaching and other consulting from this point of view.
Agile isn't daily meetings, user stories, continuous integration, product owners or other related activities, artifacts or roles. Agile is a mindset of collaboration to create great products incrementally and iteratively, frequently adjusting based on changes in the world around us and what we learn.
A group of people could work in a way that is Agile with a model of interaction that they invent. In other words, you don't need Scrum, Extreme Programming, SAFe, Kanban or any other framework to be Agile. However, frameworks certainly help people execute efficiently and consistently.
We created Applied Frameworks because we believe in fulfilling the needs of people and organizations to be more effective and happier in their work to produce great products that meet and exceed their customers' needs. We believe that an Agile mindset enables us to accomplish WHY we exist.
This year we want to help you and your organization find your most effective and happiest state of execution and hope this is your best year yet. Let's go!
Years ago, I was the expert for two specific products in a small development organization. When it came time for my manager to divide up the work, I always got those products to add features to, or maintain. That was fine for a while, until I got bored. I went to my boss with a request for different work.
“Who will do the work if you don’t?” My boss was concerned.
“Steve or Dave will. They’re good. They can take over for me.” I knew my colleagues. They could do the work.
“But, they’ll have to learn what you do.”
“I know. I can take a few days to explain, if you want. I don’t think it will take a few days to explain. They’re smart. I’m still available if they have questions.”
“I don’t know. You’re indispensable where you are.”
I faced my boss and stood up. “No one is indispensable. And, if I am, you should replace me on those systems anyway. What are you going to do if I leave?”
My boss paled, and asked, “Are you planning to leave?”
“I don’t know. I’m bored. I want new work. I told you that. I don’t see why I can’t have new work. You need developers on these projects.” I named three of them. “Why do I have to stay doing work on the old stuff when I want to do new things. I don’t see why I should. Just because I’ve been doing it for a year is no reason to pigeon-hole me. No. I want new work. I’m not indispensable. You can hire someone and I can train that person if you want.”
My boss reluctantly agreed to let me stop working on the old systems and work on the new projects. I was no longer indispensable.
The problem with being an indispensable employee is that your options are limited. Your boss wants you to keep doing the same thing you’ve always done. Maybe you want that, too for now. The problem is that one day, you realize no one needs what you do. You have become such an expert that you are quite dispensable. You have the same year of experience for several years.
Instead of being indispensable, consider how to help other people learn your work. What do you want to learn next? You need to plan your career development.
What do you do if you’re a manager, and you have indispensable employees? “Fire” them.
I’m serious. When you have people who are indispensable, they are experts. They create bottlenecks and a cost of delay. If you need flexibility in your organization, you need people who know more than one area. You need teams who are adaptable and can learn quickly. A narrow expert is not what you need.
When I say “fire” people, I mean don’t let them work on their area of expertise alone. Create a transition plan and help the expert discover new skills.
Why should you do this? Because if not, people and projects across the organization decide they need that person. Sometimes with quite bad results.
This month’s management myth is based on a true story. The organization wanted an expert to change teams and move. All because of his expertise. That’s nuts. Go read Management Myth 36: You Have an Indispensable Employee.
Thanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations. It is available for purchase (only $2.99) on lulu.com (that’s where the link goes). Here is the blurb about the book:
Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular AgileAdvice.com blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including “Agile Mining at a Large Canadian Oil Sands Company”, “Crossing the Knowing-Doing Gap”, and “Becoming a Professional Software Developer”. Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.
Once you have read it, I would love to hear your feedback and reviews here. I will try to publish updates quarterly over the next year to make it even better! Thanks again for your support.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
I’ve spent most of my career writing bad code – code that is ugly, hard to read, hard to understand, darn near impossible to update and fix problem. It’s bad code, not because it didn’t satisfy the original needs, but that it did so in a way that was not maintainable.
Most people (myself included) look at the code they just wrote and think about how great it is; how it’s so easy to read and understand, and how they will be able to use this code to do so many things. The thing that we forget, is that we are always looking at the code we just wrote through the eyes of context and short term memory. Of course I understand how that function works – I just wrote it. But in a few months, weeks, days… sometimes hours? Well…
For most of my career, though, I’ve had this lofty ideal of writing great code all the time. Worse yet, I’ve had this delusion that my code is somehow better than the code that I was reading from other people. But as I continue to grow and learn, in invariably look back at my old code and think about how bad it is. I’ve come to realize – albeit slowly, over many years – that this is ok for a couple of reasons.You’re Learning
Most of the bad code that I write is because I’m learning – learning a new language, a new framework, a new tool, a new API, a new … something. When we’re learning, we don’t know the answers yet. That’s why it’s learning – to find the answers.
To find the answers, though, we have to solve the problem at least once – and there’s a good chance that the code we write will be bad, the first time we solve it. We can’t be concerned with good abstraction, clean code, elegance, simplicity or maintainability when we’re in learning mode. We have to focus on succinct, to the point, solve the immediate problem styles of coding with little to no regard for 10 minutes from now, let alone 10 days from now. This is the nature of learning.You’re Ready To Learn
If you know you’re writing bad code, then you’re already one step ahead of the game. Knowing that the code you’re writing is a sign that you know you can improve. It’s a sign that you want to improve. It’s also a sign that you are ready (or almost ready) to take the next steps to improve.
Recognizing your own code as bad code is a sign of learning. That code you wrote 3 months ago, which you are now embarrassed to look at? That’s a good sign. It means you’ve learned since then. The code you’re writing for your current project, which keeps giving you bad feelings and making you nervous? At least that is recognition of the need to learn.
Recognizing your own code as bad is one of the best things you can do for yourself, you projects and your career because it means you want to learn and improve.The Learning Experience
The real problem with bad code isn’t the code itself. The real problem stems from confusing the learning experience with solving problems for production systems. Far too often, we allow code that we know is bad to become production code. Sometimes this can’t be helped. Sometimes it isn’t a bad thing, either. But most of the time, the bad code that we wrote while learning shouldn’t be put in production.
Learning should be done in throw away projects, samples and demos. Rather than trying to learn how to use that library in your production code, build a demo app that mimics your production needs (to a minimum). Instead of deciding to use a new framework for the first time when starting a new project, take some time to play with it first. Dig in a little deeper than you think you need to, and try to understand how it works and why.
Separating the learning process from the production code process is important. Taking the time to learn how to solve a problem will produce better code and better understanding of the problem when you get back to your production system. You’ll be better equipped to deal with edge cases, additional requirements and other issues that don’t show up the first time you solve sometime.Write Bad Code
You may not always have control over timelines. You might not have time to write a sample project for every idea., and sometimes you don’t have a choice but to release bad code. This is the reality in which we live. But I encourage you to to try, whenever possible, to write bad code knowing that you will be throwing it away once you start working on the production-ready solution.
How often do you get to the end of the week or month at work and wonder what you have achieved? Day to day reactive work can easily eat away all your time. The best way to counter-act this is to have a plan and make it visible. That way you can constantly be reminded of what you should be focusing on. This simple one page template is quick and easy to fill out, and will help keep you on track during the month. You can use this template for yourself or for your team. In fact you could use the template for a retrospective action.
You can download a high res version of this image to print here: Download
First pick a focus for the month. Maybe you want to try use email less and rather speak to people face to face. It is best if this is quite specific, that way you are more likely to do it. Fill in this focus on the left hand side.
Underneath add a few reasons why you have selected this focus. List the benefits of doing this: i.e. for using email less, the why might be to help reduce misunderstandings, to build relationships or to reduce the time to get answers.
Next think of a way to phrase this as an experiment. The idea behind this is to figure out if you actually achieve the expected benefits with this focus. For example: If I walk to the Product Owner’s desk rather send an email I will get an answer in less than 5 minutes instead of waiting 4 hours.
Now is the time to get specific. This doesn’t have to be a complete task list, but should include the important items. If the focus is a behavior change, then write the tasks you usually do that you would like to change how you do them. E.g. when the team has a question about requirements, instead of emailing the PO, go talk to him.
Check in Dates
To help keep you on track, you should check in with your plan once a week. Set up 30 minutes each week. Schedule it in your calendar now and write down the times.
When it gets to the check-in ask yourself the following questions:
- How well have I stuck to my focus?
- What data have I collected to prove of disprove my experiment’s hypothesis?
- Have I done the tasks I listed? Are there new ones? Are some no longer relevant?
- What do I need to change in the next week?
Finally at the end of the month, schedule an hour to think about how this worked.
Consider the following questions:
- How did the monthly plan impact the work I did?
- What impact did having this focus make on the month?
- Who noticed this focus and what were the side effects?
- How did the check-ins work for me?
- What would I change next time I do this?
- What did I learn that was unexpected?
- What is the result of my experiment?
I have posted my most recent Pragmatic Manager newsletter on my site. Read Johanna’s 2014 New Years Tips.
I have a question for you. I send the newsletter to my subscribers the last week of the year. I call them “this-year” tips. Some people ask me if I mean “the next year”. I don’t because it’s this year. Is this confusing? Should I rename my end-of-the-year tips? Thanks for your feedback.
Traffic-wise, Los Techies saw growth year-over-year in behavior:
I have no idea if these numbers are good or not, but “green” seems good and “red” seems bad. Pageviews clocked in at over 4.5 million, and that seems like a big number. For comparison purposes, we had 2.5 million in 2012, growing by the same number but a slowed rate. 2014 also marked the year of the death of Google Reader, which brought our subscriber count from Some Big But Probably Wrong Number to a Smaller But Who Knows This Seems Made Up number. Time spent on LT also went down, which I’ll dig into shortly.
All time, we’ve received 15M pageviews and 11M unique pageviews, which means that between 25-30% of our traffic all time came within the past year.
How did individual posts do? In this list, we see a mix of old and new:
The all time numbers are pretty funny, “one of these things is not like the others”
Many moons ago, we were hosted on a .NET blogging engine whose name I have burned from my memory. Naturally, older posts dominate the all-time list simply because they’ve had longer time to accrue pageviews, similar to old Stack Overflow answers that I’m slowly milking my way to 10K rep.
How did individual bloggers stack up? You might not ask this question, but I did, being a narcissistic sort of fella.
I win! Something. Interestingly, although I received over 40% of total pageviews, users only spent less than a minute on my blogs. Derick gets over 4 minutes of eyeball time. My bounce rate is waaaaaaay lower than others, but I have no idea what it means. I choose to believe it’s like a golf score, and lower is better. Or more likely, others wrote longer, more descriptive, and less ClickHole-worthy posts than I.
I’d pull up acquisition numbers, but it says that 75% of our traffic came from organic search, and 97% of that came from the search term of “(not provided)”. I can only assume this is because one of our bloggers wrote about Heartbleed, and Google retaliated by removing those inbound values.
Finally, where did our users come from?
Mostly the US, but also some EU/UK, and a small number coming from across the other pond.
Browser-wise, it’s still dominated by Chrome:
We see some unfortunate souls using “Mozilla Compatible Agent”, about the least sexy browser name I’ve seen. Waaaaaaay down the list I can see browser agents of “Do not spy on me!”. Done and done. I also see people using their game consoles, as “Nintendo Browser”, “Playstation Vita Browser” and “Playstation 3” show up on the list. I don’t know about you, but right after I’m done with yet another Skyrim session, I go straight to learning about Angular on my TV.
Interestingly enough, we don’t a lot of mobile traffic – 92% of our traffic comes straight from desktop. On the desktop, Windows beats Mac 3 to 1, and Linux 8 to 1. Of those mobile hits, about half come from iOS, 44% from Android, and the rest from Windows Phone/BlackBerry (?!). Not exactly what I expected, where supposedly mobile is a thing.
All in all, I’m proud of the content we put out this past year. Thanks again to all of our readers, and sincerest apologies to mine. Here’s to a great new year, more great content, and if we get around to it, another Pablo’s Fiesta.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
Two nights ago I had a great discussion with my son, Justice Berteig, about how we have been managing to do house cleaning every week. We have been using a very basic Kanban system. I have created about 100 stickies each of which has a basic cleaning task such as “tidy the kitchen counters” or “vacuum the office floor” or “clean the powder room toilet”. If we do all of the tasks, it represents a fairly complete cleaning of the whole house. Every Saturday morning, all six of us (myself, my wife and our four kids) choose one task at a time and put the sticky for that task in the “In Progress” column. When we finish a task, we move it to the “Done” column. When all the tasks are done, we all are finished. We reuse the stickies each week. Sometimes if we want to do a quick clean, we won’t put out all of the stickies.
It works well in one specific way: everything gets done!
But Justice was complaining about the system because he works a lot harder and one of my younger kids has admitted to doing less than she could… because she can get away with it with this system.
Last week we tried a modified system where each person has a task allocation. For example, Justice had an allocation of 25 tasks. Our younger daughter had an allocation of just 5 tasks. We then took turns to choose one task at a time (although there were a lot of exceptions to this) until all the tasks are pre-allocated (similar to how teams used to do Sprint Planning). But, although some people finished all their tasks, not everyone did and so there were a number of things left over that never got finished.
In other words, we stopped using a Kanban system, and we stopped reaching the overall goal of a clean house.
So Justice and I had a long conversation about this problem. In the interests of continuous improvement and experimentation, I didn’t just force the issue back to the old Kanban system. Instead we decided to try the following changes:
- Limit the tasks to only those in common areas. Private areas such as bedrooms would be taken off the master list.
- Each task would get an estimate from a scale of 1 to 3 to represent their relative difficulty. We will talk as a family about the estimates and maybe use a simplified “bucket system“.
- Now, instead of an allocation of a specific number of tasks, the allocation would be for a total amount of effort. We agreed that our youngest would get a smaller allocation still, but she could take any number of tasks to fill it up.
- We also agreed to be more disciplined about taking turns to choose tasks.
I’m going to add one more thing which is to do a specific retrospective on how it worked to see if we can come up with further improvements. I have to admit that I hope we go back to the Kanban approach!!!
Check out our new Kanban training offering: Kanban: Gentle Change currently available for public enrolment in the Toronto area and for in-house delivery wherever you might be!Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Most great leaders are calm and take things in their stride. Rarely are they seen running around like headless chickens. Yet, most managers seem to be constantly running around putting out fires. What would it look like if those managers instead focussed on being great leaders? If this sounds interesting, try the following steps to start being more proactive rather than reactive.
Take stock of what you are busy with all day every day. We recommend a journal that for 1 week, that you update at least every hour. A one-liner is all you need. Try and be more specific than a generic “admin”.
Set aside one hour after this week to look at your journal. Place each of your tasks into the appropriate quadrant below. Think deeply about what value really means to you and your business.
The items in quadrant 1 are great, you want to do more tasks like this. The items in quadrant 2, you want to look at in more detail and try and reduce the time they take without removing any value. Is there something you can automate? Or simplify?
The items in quadrants 3 and 4, you want to get rid of. They are adding little if any value. What would happen if you stopped doing them? Can you delegate them? If they are needed – how can you make them more valuable?
Do this exercise every month or so, you’ll be amazed at how many non valuable things creep onto your list. Set aside time, at least 4 hours a month, to improve your processes and remove non valuable clutter from your to do list.
At the beginning of each of the past three years, I have compiled a small list of resolutions for Scrum Masters to consider for their own personal development journey for the upcoming year. It’s hard to believe 3 years have gone by already – time is flying. You can read the resolutions from the past at these links:
The suggestions this year come from direct involvement or observations with agile teams I have worked with during 2014. So here they are, the 2015 resolutions for all of my amazing Scrum Masters friends out there. We are all works in progress!
Slow down (to speed up). By this, I mean you, dear Scrum Master. Far too often, I find Scrum Masters demoralized, burned-out, stressed or unappreciated. There are many reasons for this including typical organizational pressures to deliver results at any cost but for now, we can only start with you. Resolve to take a breath from time to time and allow things to just happen. Allow for a bit of chaos. Allow for a few experiments and “failures.” Besides, when everything is perfect, nothing happens.
By slowing down and becoming more mindful, you will find yourself with the time and space to enjoy the deep responsibility you have been given as a Scrum Master. The opportunity to help guide an organization (or your team) to become connected, resilient, and productive will require a healthy and vibrant you.
Let go (to gain more). This is a hard one as it is always hard to intentionally let go of control, especially if you are accustomed to having it as a project manager. I touched on this with the resolutions from last year but I still feel this is an area for many Scrum Masters to grow. Resolve this year to continue to identify areas to reduce the teams dependence on yourself so others can shine. While this doesn’t feel intuitive (or like a good deal), the feeling you will receive while serving your team and watching them produce will be worth it.
Focus on experiences (not just process). While ensuring the mechanics of agile are properly adhered to may feel important (and at times, they are), ask yourself if the team is stronger and better because of it. Many teams become frustrated with an agile implementation when things feel dictatorial – sometimes feeling worse than before attempting agile. Resolve this year to design and shape every team ceremony and activity into a positive and memorable experience. Shameless plug…my book, Becoming a Catalyst: Scrum Master Edition, covers many examples of how to do this.
Have a fantastic 2015 and as always, contact me if you need anything.Becoming a Catalyst - Scrum Master Edition
Okay… this is going to be a precursor to a more fully developed whitepaper, but I want to see if I can tightly articulate the LeadingAgile approach to designing and executing an enterprise agile transformation. This post is going to focus on the ‘what’ and leave out the ‘why’ and the ‘how’ for the time being. We’ll get back to those as the conversation progresses.
Any agile transformation starts by understanding of what the end state of your organization looks like and how that organization will coordinate to produce integrated value for your customers. We do not believe that these patterns are intuitive or that most organizations will emerge into them. Therefore we define them up front. Think about this as the architecture of your agile enterprise.
That architecture is made up of the following 3 key areas:
1. Structure – This is the pattern for how your organization will form teams at all levels of the enterprise. At this point we aren’t being dogmatic about how teams will form, just that whatever teams are defined, are generally permanent, have everything necessary to solve the problem they are assigned to solve.
2. Governance – Governance is simply the way in which your organization intakes work, makes decisions about priority, balances capacity and demand, and handles tradeoffs when things get out of balance… as well coordinating across teams when necessary. You need to have some idea of how you plan to do this… and agree to that plan… before you get started.
3. Metrics & Tools – Metrics are the way we are going to measure organizational performance. We need a way to baseline these metrics, gather the metrics, show improvement, and communicate those metrics to the appropriate stakeholders. We can pretend tooling is not part of this conversation, but at any level of scale, tooling is part of the conversation… so let’s figure it out.
Any large scale architecture, organizational or otherwise, is just a bunch of theory until you exercise it and prove that it works. I learned from Alistair Cockburn the notion of a walking skeleton, and that is exactly what we need here. The smallest instantiation of the whole thing that proves it will work in your organization, with your people, and your culture.
At LeadingAgile, we believe in an incremental and iterative approach to adopting agile. That said, we wanted to stay away from the words ‘incremental’ and ‘iterative’, as well as words like ‘phases’ and ‘milestones’… in part because they are jargony and overloaded.. but also because they can carry connotation that we don’t necessarily want as part of our transformation approach.
Here is how we describe our incremental and iterative approach to an agile transformation:
1. Expedition – An expedition can either be a group of people that go on a journey or the journey itself. We are using the word as the group of people making the trip. A LeadingAgile expedition is the group of teams that are going to exercise the architecture we’ve defined for the organization. An expedition will form teams at all levels, use the governance model, and leverage the metrics and tools.
2. Basecamp – Extending our Expedition metaphor, a basecamp is a place on the trail where we have made a predetermined, measurable amount of progress and can therefore regroup, refuel, and rest as we prepare for the rest of the climb. A basecamp in the LeadingAgile framework represents a predetermined amount of progress in the transformation journey and its associated business outcomes.
3. Trek – Different groups within the same company won’t necessarily have the same goals with regard to their transformation, nor have to take the same path to get there. A Trek is one of many paths and consists of many different possible Basecamps along the way. An organization may define one or more Treks made up of one or more Basecamps to move the organization closer to its goals.
What we are basically saying here, is that in the presence of a known set of business goals, a known pattern for achieving those goals, and an established plan for how we can get there… we can systematically increase our chances of success in the transformation process. Furthermore, there is no magic involved.
It is simply a pragmatic understanding of how the organization intends to operate and incrementally and iteratively helping it operate that way.
This kind of journey can be defined, scheduled, put in a Gantt Chart, planned and funded. You can measure progress against the plan, progress against goals, progress against business metrics and 100% determine if the investment that is being made is yielding the business outcomes you are trying to achieve. If it’s not, you can stop.
Speaking of which, that leads us to the next set of steps…
1. Baseline – There are two things that can be instrumented in an agile transformation. First, you can instrument the transformation itself, you can measure that you are doing what you said you were doing, but more importantly you want to measure that you are achieving what goals you set out to achieve. This first means understanding where you are at in terms of sustaining the practices, but also establishing a baseline set of business metrics from which to measure improvement against.
2. Measure – As you go about the day-to-day activities of forming teams, training teams, and coaching teams, you want to be able to understand if the processes and practices are taking hold and the best way to do this is to have the team self assess if they are able to continue in these competencies once the coaches have gone. You also want to be able to correlate the sustainability of the practices to the improvement of business outcomes and show progress over time.
3. Improve – If what you are doing at the execution level is not improving the metrics, retrospect as to why and change the plan. If we have the wrong architecture… revise it. If we defined the expeditions and basecamps incorrectly… modify them. If the training and coaching we’ve prescribed isn’t working… do something different.
The Manifesto says that we value responding to change over following a plan. It’s not the presence of a plan that is the problem, it’s resisting change when we learn something isn’t working. There is some work to do here to explain the why and the how behind some of this… but from what we are seeing on the front lines… doing this with real companies… this approach works.
1. Define one possible end state
2. Incrementally and iteratively implement that end state
3. Measure, inspect, and adapt along the way
4. Change direction as necessary
All I am saying here is that we believe it’s not likely most organizations are going to self-organize into an agile enterprise operating at scale. It is possible to define a roadmap, articulate what the intermediate steps look like along the way, and communicate what you should be able to expect as you are going down the path on this journey.
As a quick aside… I am running my first full marathon next Sunday. A read a great book that took me through a week by week explanation of what would happen and what I would feel as I trained. It told me what week I’d want to give up and what week my toenails would fall off. It wasn’t exactly on point, but it sure helped manage my expectations.
It is knowable when you’re toenails are going to fall off.
I want us to stop thinking that transformation is a mystical process of self-discovery. We are talking about businesses… ongoing concerns… that exist to make money. We need to get better at telling people what it will take, how much they will have to spend, and what it will look like when we are done. My take is that this stuff is knowable and can be planned.
More on the why and how over the next few days.
The post What It Takes to Develop an Agile Transformation Strategy appeared first on LeadingAgile.