Recently, I was engaged in a lively conversation about enterprise agile transformations and the topic turned to Project Management Offices (PMOs) and, specifically, Project Managers (PMs). The gentleman I was speaking with said that in ideal agile, there is “no need for Project Managers”. His argument was that they are replaced by Product Owners, Delivery Teams, ScrumMasters, and/or Functional Managers.
At first glance, there may appear to be merit to his statements. Let’s look at some of the evidence:
- In most agile methodologies and frameworks, there is no Project Manager role. In fact, there might not be projects at all.
- No need to build teams around a project – teams are stable and work is brought to the team.
- No need to manage scope and build detailed GANTT charts – that is done by Product Owners through a well-defined, prioritized backlog.
- No need to gather individual estimates – that is done by the teams progressively.
- No need to gather individual progress status – that is done through working, tested software and burning down work.
So was the gentleman correct? I contend that he was not, especially as you start to scale agile in larger organizations. In fact, in my experience, buy-in and alignment of the PMO and Project Managers could make or break your transformation.
I will not deny that the traditional role and responsibilities of a Project Manager changes and may be distributed in agile, however, the skills and experience PMs bring to the table are extremely valuable.
Effective Project Managers have good organization and communication skills. They are well versed in risk and dependency management. They understand ways to manage time, cost, and scope. They know the organization and how to remove impediments.
So what becomes of Project management in an enterprise agile world? There are many roles a traditional Project Manager can play. One such role is as a Portfolio Manager on a Portfolio Team.
The Portfolio Team is responsible for setting the vision and strategy, deciding on initiatives in which to invest, and ensuring value is aligned with business strategies. The Portfolio Manager helps make sure that the team has everything it needs to function effectively. This goes beyond just scheduling recurring meetings. The Portfolio Manager can act as a servant leader, removing impediments, measuring progress, and enabling the team to make decisions on the portfolio.
The Portfolio Manager is the facilitator for the team. They help keep the team accountable to adhering to processes and working agreements, as well as ensuring the team operates efficiently.
Another role could be that of a Program Manager on a Product Owner team. As an organization scales, it becomes difficult to manage dependencies and risks. It becomes overwhelming for a Product Owner to provide clarity of the backlog to their delivery teams.
By forming a team around a Product Owner, many individuals can lend support and capacity to the Product Owner, providing delivery teams that backlog clarity. A vital part of that team is the Program Manager. They help to clear impediments, manage dependencies and risks, hold the team accountable to providing all the things necessary to ensure the delivery teams are never starved of requirements. They can also serve as an escalation point for blocks and issues that cannot be resolved within the delivery teams.
Other areas and roles a traditional Project Manager could serve or grow into include Release Manager, ScrumMaster, Community or Practice Lead, Product Owner, or Internal Coach. I tell Project Managers to really think about their long term career goals and be proactive in pursuing those areas of interest.
The biggest lesson I try to impart is how to be a servant leader. Changing your mindset from directing to serving can be difficult. But, in an Agile world, servant leadership is what is needed to be truly successful. Enabling others to be successful, will make the organization and the individual successful. When the teams win, everyone wins.
I encourage Project Managers to seek opportunities where they can help the organization and the transformation. With a Project Management background and a servant leader mindset, PMs can grow into incredibly effective agents of change.
Encapsulate Collection – Become part of a supportive team who inspire, celebrate and learn together
Collapse Hierarchy – Build relationships inside and outside the team, share your passions with all
Remove Middle Man – Go direct to your customer, understand their needs, loves, frustrations
Extract Method – When valuable patterns evolve encapsulate and name them for all to share
Replace Magic Number with Symbolic Constant – Replace fear of looming deadlines with the courage to do things well – quality always pays
Preserve Whole Object – Leave nobody out, value contributions from all, diversity breeds creativity
Replace Error Code With Exception – When somethings not right be honest about why, raise it, let your team help you catch it
Self Encapsulate Field – When you need some space to think go and find a field to walk in
If you’ve been following the progress of our magnificent Git client, GitKraken, you’ve probably figured out that our long-term goal is to keep you—the fearless developer—in app and enjoying your life rather than clicking out to some other application. We know you have zero time for that dance and thus we present to you…drum roll please…v1.3! Now with multi-select commits and more keyboard shortcuts.X-Ray Glasses for your Commit History
Ever wish you had super powers? Aside from flying or controlling the weather, what if you could slide on a pair of snazzy 1950’s style x-ray specs and see history. GitKraken makes that a reality!
“Previous to this update, you could only select one node to show you the changes that were in that particular commit,” says Jose Garcia, Developer at Axosoft. “Now you can choose multiple commits on the graph and it will show you the combined changes.”
This new update is yet another way you will be able to stay in-app and not have to interrupt your workflow.
We get it. We’re developers too. So, we know that it can get annoying to individually look at every single commit along the way just to see what’s been going on.
Garcia explains what he would have to do before this update: “I would actually have to go to GitHub and open up a new pull request just to see the entire list of combined changes. Now I can do that in-app. I don’t have to leave GitKraken, and it saves time.”
“When you select a commit you’re looking at the diff—or change you made. Now you have the option to select more than one commit. So you’re looking at the combination of those changes,” affirms Kyle Smith, Developer at Axosoft, who worked on this update.
Selecting multiple commits works similarly to selecting multiple files in your Finder or File Explorer. Hit ⌘ + click (Mac) or ctrl + click (Windows/Linux) to select an additional commit, or hit shift + click to select a range of commits. Now you’re looking at the combination of all those changes. And cooking with gas.
Story time, boys and girls, gather ‘round: let’s say that you’re working with a teammate and you want to see what changes they made. This is easy peasy in GitKraken. “You can select and see all the changes he or she made over the last week,” illuminates Smith.
This isn’t Facebook stalking. This is just making sure all is A-Okay before you move on and deem your project done.Choosing multiple commits
“If you select two commits, you’re viewing the diff between those commits. If you select more than two commits you’re viewing all the diffs those commits introduced combined into one.” And now you can view and review!
“This is typically done on GitHub,” says Smith, but now, yup, you guessed it, you don’t have to leave the app. In addition, the review could become tedious (not unlike Facebook stalking). “Before we made this update, the reviewer would have to examine each commit and keep those changes in their head. Now you just select a whole chunk and view all the changes.” Neat-O!Go Ahead, Take the Shortcut
If you’re in a hurry and like to fast-track things… grab your coffee, Mountain Dew or rocket fuel and buckle up! Here are the keyboard commands that are a fast pass to party land.More keyboard shortcuts, more fun!
“You’ll see the commands in app when you update,” says Garcia. Also, hit ⌘ + / (Mac) or Ctrl + / (Windows and Linux) to see the full list. Bam!Can you Get a Little Closer?
Can’t see so good? Got a little screen? Are you feeling like Alice in Wonderland and things are too big? Whatever your issue, you can adapt the app to your vision comfort level.
We’ve added the ability to zoom in and out!
⌘ or Ctrl plus + : Zoom in
⌘ or Ctrl plus – : Zoom out
⌘ or Ctrl plus 0 : Reset zoom
Ah, much better. No more eye strain.We’re Listening to you
You can see we’re super interested in what you want. We’re really paying attention. Not just because we think you’re cool (you more than likely are) but, because we want to make the most kick-ass Git client in the world—one that you’ll actually enjoy!
“If there’s a lot of people asking for something, we take it to mean that’s a limitation of the app and something can be improved,” explains Garcia. “We can’t grant every request, but if something sticks out, we’ll try to do it.”
When you want to give us feedback, click the “Provide Feedback” box on the bottom right corner of GitKraken. We can’t deliver take-out, but that information is delivered right to our project management tool—Axosoft. It’s another tool we’ve made for devs to manage projects. Check that out too.
Recently, I’ve been doing a lot of reflecting on how to increase personal agility. No, I’m not talking about doing somersaults or some crazy yoga poses. I’m speaking of the ability to focus on the delivery of value and be adaptable in what I do every day. When the Manifesto was written back in 2001, there were representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others present. They focused on values and principles that would improve how we do software development. But, can we apply the same practices to our personal lives? I’ve been looking to answer that question since 2010, when I started to write about Personal Kanban. For me, Kanban doesn’t get the love it deserves, as a tool to help manage personal activities and outcomes. When people talk about agility, they usually think Scrum. I realized Scrum is being leveraged outside of software development. I was even approached recently to comment on “Agile” Marketing by using Scrum. It got me thinking… Why do people think Scrum will solve all problems? When it comes to organizational agility and specifically personal agility, I don’t think it does.Scrum for One?
For the sake of this post, I want to keep focus on people and not big organizations. Having been an Agile coach and consultant, I have learned a lot of strategies that have helped me manage customers and accounts. While working with large complex organizations, I have seen productivity improvements on organizational levels by leveraging Lean and Kanban and on a team level by leveraging Scrum and Kanban. But what about all of the individuals who work for those organizations or on those Scrum teams? What about people who have no idea what Scrum is and don’t care? How can they better their productivity outside the software world?
In the Lifehack article “Scrum for One,” Dustin Wax described how many of the elements of Scrum could be adapted for individual productivity. When reading the article, I wasn’t sold on the idea. Scrum is an awesome framework for teams but I see it like jamming a round peg in square hole, if you want to use Scrum for your day-to-day productivity.
In Scrum, you demonstrate value to your customer or customer representative every 2-4 weeks, as part of a sprint (timebox). Does that make sense for managing your personal work on a continuous basis? No.
In Scrum, you have a 3 roles: ScrumMaster, Product Owner, and Team. Unless you have a split personality, it’s just you!
If the metaphor doesn’t align with reality, find a new metaphor versus trying to bend reality to reflect it.
Most of the things I think about when getting things done include: Aligning activities to outcomes, breaking work into managing chunks, iterating on what I’m doing or creating so it can be delivered or improved over time… With that, these are not elements exclusive to Scrum. So, why limit yourself to Scrum?Personal Agility Manifesto
I believe personal productivity (or agility) could to be rethought. Is personal productivity about being really busy or is it about getting things done? To be productive, it means you must produce. If not, you are just active. There is a difference! To help shape my thoughts, I wrote my own principles of a personal agility manifesto. It’s a lot like the Agile Manifesto.Principles of Personal Agility
I follow these principles:
My highest priority is to satisfy myself and then others
through early and continuous delivery of valuable outcomes.
Welcome requests, even late in the day.
Agility harnesses change for my competitive advantage.
Deliver outcomes frequently, from a couple of hours to a couple of days, with a preference to the shorter timescale.
Work together with others daily.
Outcomes are completed by me being motivated.
Get the environment and support I need, and get the job done.
The most efficient and effective method of conveying information
to and from others is face-to-face conversation.
Outcomes are the primary measure of progress.
Agile processes promote sustainable outcomes.
I need to maintain a constant pace indefinitely.
Continuous attention to technical excellence and craftsmanship enhances my agility.
Simplicity–the art of maximizing the amount of outcomes–is essential.
The best outcomes emerge from me being a self-organized individual.
At regular intervals, reflect on how I can become more effective,
then tune and adjust my behavior accordingly
First, (any) outcomes are the primary measure of progress. This isn’t all about software development.
Second, I’m focused on minutes, hours, and days to get things done. Teams will continue to focus on days, weeks, and months to get work done and shipped.Conclusion
I’m looking to dig into something anyone, within or without an Agile team, can use to improve personal productivity. When you hear “Agile” it’s actually a pretty niche group. But, when you talk personal productivity, the audience size explodes. Like with agile, I don’t think there is a single right way. So, I’m looking to experiment and continue to try and get better. So, if you are an individual, you can be agile for one. If you have any tips or tricks on how you get things done, I would love to hear them.
Agile teams gebruiken retrospectives om continu te verbeteren. Verbeteracties richten zich vaak op de manier waarop het team samenwerkt om de productiviteit te verbeteren. Uit een retrospective kunnen ook acties komen om de kwaliteit van het product te verbeteren. Bijvoorbeeld door verbetering van de manier waarop er getest wordt.
Tijdens een agile retrospective die ik faciliteerde kwam naar voren dat er veel software fouten gevonden waren in de systeemtest. Deze testen werden niet door het ontwikkelteam gedaan, maar door een apart testteam.
Zoek de oorzaak
Mbv een 5 keer waarom retrospective oefening werden de fouten geanalyseerd. Daaruit bleek dat het om functionele fouten ging, die door het ontwikkelteam tijdens de iteratie gevonden konden worden.
Een van de grondoorzaken was dat de test strategie die aan het begin van het project was opgesteld niet voldeed Er ontbraken regelmatig test cases in de funtionele test, waardoor er fouten doorheen slipten
Besloten werd om een verbeteractie te doen: voor iedere user story zou voortaan een acceptance test geschreven worden, die zou bestaan uit een lijst met functionele testcases die het team uitvoert. In de definition of done werd toegevoegd dat alle testen de status passed moeten hebben voordat de user story af is.
Door dit consequent te doen ging het aantal functionele fouten wat in de systeemtest gevonden werd aanzienlijk omlaag. Deze fouten werden al eerder gevonden of niet meer gemaakt door de verbeterde testanalyse die gedaan werd voordat de ontwikkelaar de software schreef.
Met de 5 keer waarom oefening in de retrospective leerde het team van hun fouten en definieerde ze acties om in de toekomst soortgelijke problemen te voorkomen.
Het uiteindelijke doel van retrospectives is om continu beter te worden. Wat beter precies is, dat weet het team het beste. Immers de teamleden weten hoe ze hun werk doen. Met de retrospective krijgen ze inzicht wat er goed gaat en wat beter kan.
Waardevolle Agile Retrospectives
Wil je meer weten over retrospectives? Luis Gonçalves en ik hebben het boek Getting Value out of Agile Retrospectives geschreven. Dit boek is vertaald door een team van vrijwilligers naar het Nederlands: Waardevolle Agile Retrospectives. Het boek helpt je om voordelen te halen uit het doen van retrospectives.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
It was a hot winter afternoon in Scottsdale, Arizona, which sounds confusing, but if you live in the desert you know how the heat can creep up on you like a wool sweater.
I was wearing a black vegan leather jacket (plastic); black cotton t-shirt, cheap grey watch, and Elvis Costello eyeglasses. My hair was sufficiently spiky, due to 8-great-hours of sleep. I was happy, caffeinated and sober and I didn’t care who knew it. I was everything an unofficial private detective ought to be.
I made my way into the café at 12:00pm. A little place on the corner of Fake and Mall, known as American Girl Café. The joint was filled with every shade of pink imaginable. It was like 500 pounds of bubble gum got into a street fight with a gang of flappers, then they turned around and started wrestling a bevy of drag queens, then they started throwing streamers at an angry mob of pink flamingos and… you get the point. It was real pink.
I was feeling lonely, longing for a small doll made in my likeness to keep me company, shoot the breeze with, be forever a friend, you know, junk like that… “Excuse me,” I said to the old guy wearing a stained pink apron with a facial expression to match. “Can I get a doll?”
He gave me the once over. I’ve been given the once over by better. That’s just part of the job when you’re an American girl, like myself, who looks like an Italian guy.
Old Apron Face scurried away. He came back with a dame who had seen better days herself, but she genuinely wanted to help. “Can I help you, Sir? Sorry, ma’am?” She asked.
Her chipped fingernails were the same color as the pink placemats on the high diner countertop. “Yeah,” I said, “I’d like to sit down and enjoy a cup o’ joe with a doll that looks like me.” The minute I said it, I realized how creepy it sounded, like I was Liberace or something. All the other girls and women in the diner had dolls that looked like them. I just wanted what was fair, my birthright as an American girl.
Pink Nails and Old Apron Face feverishly whispered to one another. I was standing one-foot away from them. I could smell their collective breath; mint mouthwash and Hubba Bubba sour blue raspberry all tangled together.
It smelled like fear and fervor and lost dreams. For some, this would have been an excruciatingly awkward situation, but for me, just a surefire way to protect myself from the ol’ bait-n-switch.
“Well…” Pink Nails began, “We have a…It’s not a problem, per se, it’s more of a…well…opportunity!”
Oh, great, I thought, another Tony Robbins disciple explaining how problems are gifts and you can’t look a gift horse in the mouth and all that claptrap. In all my years of unauthorized sleuthing I’ve learned a thing or two about those kinds of gifts, they really only feel good to the giver, because the receiver knows she got the short end of the stick.
And I’ll tell you what, if they don’t find my doll, not only am I gonna look a gift horse in the mouth, but I’m going to poke him in the eye with my short end of the stick! “Great,” I said, with all the enthusiasm of a lobotomy patient. “Let’s hear about this opportunity.”
This is when Old Pink Apron butts in. “Listen, we don’t have a doll that looks like you.”
“Excuse me,” I said, reminding him, “I’m an American girl, surely there is a doll here that looks like me!”
It was time to give it to him straight. “Listen, Ol’ Apron, girls will be boys, and boys will be girls, it’s a mixed up, muddled up, shook-up world except for Lola. Now, I know that, Ray Davies knows that, so how come this joint don’t know that??”
That’s when Pink Nails grabbed one of the “Bitty Twins.” Sounded like a mobster, so I flinched a bit, but this twin was legit. He was wearing a rainbow gingham shirt (not unlike one I own myself), his hair was dark brown and spiky. He had a twin sister (I have a twin brother).
He was alert, happy and eager to be my Emma Peel and we didn’t care who knew it!
As Axosoft’s Evangelist, my job is to stand up in front of a room full of up to sometimes 2,000 people and make connections. Oftentimes, I’m the only playwright in the room. The only woman in the room. The only LGBT person in the room. As I see it, the more I show up, the more I’m myself, the more I point out subtle (and not-so-subtle) incongruities that exist when we think everyone is the same, the more meaningful conversations we can have.
Check out #ItWasNeverADress. While you’re there, share your story about a time when you didn’t feel welcomed but clearly belonged. You may just inspire someone to stand out.
“Resources” are fully allocated to capacity, “Features” are being developed, Stakeholders are happy – what could be better?
Scratch the surface however, and this thin veneer of accomplishment begins to show the truth that lies right beneath.
It doesn’t happen overnight, and it is almost always with the best intentions, but before you know it a functioning organization becomes a dysfunctioning one – how do we let this happen? Why does it happen again and again? Why don’t we recognize the difference?
Let’s explore some patterns and solutions that can help us get out of the rut.
Dysfunction 1: Output vs. Outcome
Being busy at work is a good thing – it should mean that you have enough to do at your job that you have a day filled with meaningful activities. Not just any activities, but ones that add value to the product or project – that if you think about them, actually add measurable change to your team. This kind of day requires that there is a well managed stream of work, people who have the skills we need to perform the work, and managers that are interested in growing the skills and abilities of their team.
That is not what I usually see when I first begin working with a new organization – I see resources that are allocated to account for 40 hours a week of assignments. I see overworked and overwhelmed or underworked and underwhelming employees – I see lots of folks show up – make noise, cause distractions, crete drama and come back the next day to do it again. I see employees that find new jobs as soon as they can to get out of the dysfunction – I see others that keep the dysfunction alive to hide the fact that they produce and contribute nothing. What this usually means is that I have individuals that someone treats as place holders for space and time on a spreadsheet so that instead of having to manage outcomes they will manage outputs.
The first step we take is to treat our resources as people – when we remove the language that identifies people as things, we begin to think of people as assets. Assets are valuable and we tend to care for valuable things. The second step is to start considering what people are producing and not how many hours they are in the office. The truth is that no one is working non-stop for 8 hours a day. It is also vey unlikely that allocating people to 10 different projects at any given time will produce valuable results. What we need to do is understand that our capacity is more limited than we would like and that more work in progress is different than completing more work more quickly. Then we build teams – teams of people that can take accountability for how they do the work they do. The amount of effort that goes into managing times then applied to managing productive outcomes. It’s hard to manage time on a spreadsheet – it’s easier to manage teams of people dedicated to your goals.
Dysfunction 2: If we build it…..
Let’s just say that we have addressed Dysfunction 1. We now have a satisfied and motivated workforce – what should they be doing?
I hear this a lot when I inquire as to what and why organizations are building what they are building: If we build it, they will like it. Then I ask who is using the thing? – “No one”, who asked for the thing? – “Our VP of…”, who is talking to the customer? – “No one”.
If we build it, they will come is a great idea for a movie plot, but not so good for an organization that is spending large sums of money to build things. How did this become a common pattern? It’s not too hard to figure out why – the people we build things for didn’t like the fact that we build things without including them, so time after time of disappointment, we stop talking to each other. What does a product or technology organization do then? Now as you are reading this you say – “Well clearly that makes no sense”, but you would be surprised how often this happens. The first step here is to begin to build a partnership with our customers & stakeholders – we need to begin again from the perspective that we are all one organization with a common goal to be successful. Success can mean a lot of things, but usually it means that we are making money.
Now it’s not easy, and a bunch of people will have to check some ego at the door, but the only way to get it done is to start talking – what are our common goals?; what is our vision for our product or project?; how can we ensure that we are building something valuable and useful? In this case, let’s build backlogs. Backlogs tell us what we want to build, they give us definitive information to have conversations with our teams and stakeholders around, and they give us a view into what we are actually intending to produce.
Dysfunction 3: Truth or Consequences
The 3rd Dysfunction is the most difficult to identify and address – not that it isn’t obvious, it’s that it’s hard to see when you’re in it. The 3rd Dysfunction involves the ability to be introspective – is your company telling itself the truth or a lie? It is not unusual for someone to tell me, “we are more productive than we have ever been – our teams are cranking out software!”, digging a little deeper and I find teams building software no one will ever use, no one has asked for and no one can define the value for. Are people crazy? Are they in another world? No. They are fooling themselves that being busy is being productive – but maybe worse – they have institutionalized this way of thinking.
Dysfunction 3 is a tough one, but we can solve this one too. Let’s produce working tested software and put it into production. In other words, let’s build relationships and communication with our teams, customers & stakeholders with real feedback from real people. Let’s start listening and learning from our real interactions.
Is the journey to tackling the dysfunction easy? No. Can they be reduced overnight? No. But recognizing the patterns is the first step in addressing high functioning dysfunction.
Think Scrum’s days are numbered? Think again.
As excitement around lean software development and Kanban exploded around 2010, there was no shortage of people proclaiming that we had arrived in a post-Scrum world. Some even went so far as to predict that Scrum would soon go the way of the 8-track.
But as I look at VersionOne’s State of Agile reports over the past 10 years, it’s clear that there were a lot of false prophets. Since we published the first State of Agile report back in 2006 with 722 respondents, Scrum has remained on top of the heap as the most-used agile “methodology”.
In 2006 the numbers looked like this:
When you consider that the “Hybrid/Custom” approaches probably had a significant amount of Scrum baked into them, Scrum users made up somewhere around 50% of the survey respondents.
Fast forward to 2016, and this is what we see:
Scrum’s impact in the latest survey really shakes out like this:
- Scrum – 58%
- Scrum + Scrum/XP Hybrid – 68%
- Scrum + Scrum/XP Hybrid + Scrumban – 75%
Making some assumptions about the “Custom Hybrids”, Scrum probably comes in somewhere north of 80%.
Flipping ahead a few pages in the survey results, we see that the leading scaling approach is “Scrum/Scrum of Scrums”, with SAFe® coming in a distant second. One thing these approaches have in common is that Scrum is the team-level engine. (Yes, SAFe does include Kanban at the team level now, but it is couched within an iterative framework.)
So why is Scrum still so pervasive?
In my opinion, Scrum’s appeal has always been its simplicity: few roles, few rules, and a focus on getting to Done. That minimalism remains as refreshing two years into an agile transformation as it is on day one.
I believe that most people understand now that, even within a single organization, Scrum’s a better fit in some situations, Kanban is better in others, and some hybrid approach is better in others. There was never any basis for the methodology wars or the predictions of the ascent of one and the demise of others.
You’ll be hard-pressed to find a pure Scrum shop these days. By “pure” I mean where they’re working to the Scrum framework, while banning the use of any XP engineering practices and forbidding the use of things like WIP limits.
The State of Agile Report asks what methodology is followed “most closely”. I’d bet that if we took away the option to select Scrum by itself, the percentage of Scrum-infused methodologies would still total up to about the same as they do now.
As with everything else, the market will decide if there’s ever a clear methodology winner. One thing that’s certain, though, is that the reports of Scrum’s impending death have been greatly exaggerated.
Find out more by downloading the 10th annual State of Agile Report and reviewing archives of past reports.
State of Agile is a trademark of VersionOne Inc.
The post State of Agile: Still Scrumming After All These Years appeared first on The Agile Management Blog.
spike: evaluate TinyMCE / other options for editing text in forumWe got to the end of the evaluation, and as PO, I had more questions at the end of this evaluation than at the beginning! Why?
I think the answer can be found in the title of the spike. What's wrong with this title? First, it starts with an verb in the imperative. "Team, do this" It is not an invitation to think. Second how do we know if the we have satisfied the objective? It doesn't really say. It just says 'evaluate.'
Here's an improvement:
spike: can we eliminate our copy/paste problems by using TinyMCE?By formulating the spike as a question, it becomes clearer what is the objective of the spike. This in turn makes it easier to tell whether the spike is done.
Of course, this still doesn't answer the question of whether it is a good thing to deploy it in our context. It's a closed question and assumes part of the answer, i.e. that TinyMCE is the best solution. How about:
Which forum editor best satisfies the needs of our users?Of course, that might be a bigger spike, but the goal is clearest and most focussed on the people who really matter!
In my Certified Scrum classes, I demonstrate using Scrum in the class by organizing the class with Scrum. The course topics are the product backlog. I used to define the product backlog as user stories, but I now express them as questions. My students ask questions; learning is the result of asking questions; and formulating the product backlog as a series of questions seems like a natural approach. I wonder questions as backlog items could be used for other kinds of story as well?
As you guys probably know, the Agile2016 conference is in Atlanta this year. What you might not know, LeadingAgile is in Atlanta as well. Given that the conference is in our home town, we’ve decided to throw a big, big party and all you guys are invited.
with special guests Kick the Robot
July 27, 2016
The Tablernacle, Atlanta, Ga
Doors open 7:00 PM
We’ve rented out the iconic Tabernacle, within walking distance of the conference, and have enlisted my favorite band in the whole world… Collective Soul… and one of my new favorite bands… Kick the Robot… to come entertain us.
And here is the cool thing… the bands are from Atlanta too!
The concert is free, but you have to register and let us know you want to attend. If you’re in town for the conference, or just simply in town, go to collectivesoul.leadingagile.com and enter the code BLOG to unlock the registration process.
You can register for as many tickets as you want until we are sold out. All I ask is if you take a ticket, please do your best to make it. We really want to pack the house and make this the most fun agile event ever.
If in the unlikely event you aren’t familiar with Collective Soul, you are totally missing out. You can find out more about the band on the registration site, or hit their website directly at www.collectivesoul.com.
I wouldn’t be surprised if you haven’t heard of Kick the Robot, they are new, but totally awesome. They are a throwback to T-Rex, the Beatles, and David Bowie, mixed with a healthy dose of Cheap Trick and the Kinks. You can check them out at www.kicktherobot.com.
As an extra special treat… Collective Soul said I could get up and play a song with them. So… you just might see me on stage with a guitar if you hang around for the encore ;-)
Really hope you can make it. See you there!
Many people have commented on the statement that Kent Beck made in Snowbird around his purpose for the meeting. I wasn’t there of course, so I am most likely paraphrasing, but the generally accepted representation was that he wanted to “heal the rift between development and the business”. As I was attending the first of the conference season
events, Mile High Agile, I started to wonder how well that has worked. I’m not thrilled with what my conclusions currently are. I’m hoping someone can show me where I’m wrong.
First, some history. This might seem a little self-indulgent, but I promise that I do have a point, if only to set some context. I discovered eXtreme Programming back around 1999. I read the book and rejected it, until I met people who were doing it. It was truly revelatory. People were happy. The business oriented folks were working together collaboratively with the rest of the team. Not at a daily meeting, but throughout the day. I started digging deeper and realized that someone had finally found a way to make software that managed the balancing act between good engineering and good project management. With that in mind, I went to the first XP Universe. I left even more energized and ready to take on the world.
The next few years were fun and challenging. Most of my time was spent practicing and evangelizing XP, and then agile came along. I continued to be part of development, and attended many, many conferences and discussion groups. And that is where it gets weird. At the early conferences, the mix between developer and manager/project manager was a little lopsided toward the programmers.
Then there was a shift and all of a sudden it was hard to find someone at the conference who wasn’t a Scrum Master, the head of a PMO, a senior portfolio project manager, CSM, CSPO, SA, or EIEIO. Several keynote speakers who I really admire started asking, “where are the programmers?” This has led me to wonder, what now? The rift was starting to heal, but it seems to be growing wider again. Far too much attention is being spent on “what processes and tools do we need” and not enough on “how can we deliver working software?” What can we do to reverse this trend?
So, now that I’ve indulged in reminiscences, it’s time to do something about it. I’m not a big fan of just sitting around arguing over a course of action without actually doing something about it. So let’s get the software development back into agile software development.
We can begin by refusing to accept a separation of “management practices” and “technical practices”. There are just agile practices. The next time we’re going to spend training money on agile stuff, let’s skip the story writing and framework training, and let’s spend it on test driven development (TDD) or refactoring. Better yet, let’s spend that time and energy on DevOps. And don’t just send “Dev” to these classes. Wouldn’t it be cool if the technical folks had the same understanding of what agile means? And the next time you’re inclined to ask for or write another report about “progress”, ask yourself “can I express this in terms of working software?”
So this is my call to action: The time for the healing to start again is now. What will you do to make it happen?
Last month McDonald’s reported its third consecutive quarter of growth (sales were up more than five percent) and beat its earnings expectations.
If you'd looked back just a year ago, however, you would’ve seen a very different story: McDonald’s had reported tanking sales and a profit loss of 30 percent.
(Image via Quartz)
So you’re probably wondering, what happened? What did McDonald’s do to turn itself around?
Here’s a hint: last October, McDonald’s implemented all-day breakfast in its US restaurants. McDonald’s CFO Kevin Ozan has admitted that serving breakfast past 10:30 AM was a factor in the company’s upturn:“All Day Breakfast certainly was a catalyst I would say and I will call it an accelerator of momentum. It’s certainly been well received by customers. It was the number one customer request that we have gotten over the last several years. So, it really was a focus on meeting customer needs.”
Don’t Skip Breakfast
Given that breakfast comprises more than 25 percent of total McDonald’s sales, you’d think that making this change might’ve occurred to the company earlier. After all, customers are more likely to eat the same thing daily for breakfast than at any other meal. And, to Mr. Ozan’s point, McDonald’s customers have been requesting all-day breakfast for at least a decade.
So why didn’t McDonald’s act sooner?
In 2006, then-CEO Jim Skinner said that serving all-day breakfast was “... not compatible with our current operating system … It’s too complicated to deliver the high quality product that we deliver at breakfast.” In 2009 the company said, of serving all-day breakfast, that,“... it’s something that we haven’t really done any extensive testing on, and we’d have to see how much that would stretch our capacities.”
This is a significant consideration, right? A new offering can’t be profitable if the engineering costs of bringing it to market are greater than the potential revenue, and it’s really hard to forecast the engineering costs and potential revenue of a new offering without doing some extensive testing.Let’s Try … Lobster
When it released another poor earnings report in October of 2014, McDonald’s chalked up its performance to “misconceptions” people had about the source and quality of its food. Rather than dwell on the last quarter, however, company executives shifted attention to new initiatives focused around customization: allowing more localized marketing and operational decisions among franchisees, and even allowing customers to get fancy with its infamously generic menu items by adding embellishments like guacamole and sriracha.
This experiment with customization wouldn’t be McDonald’s first time innovating new offerings, or testing the waters to find out what customers really want. You may recall, for example, the McLobster? People who’ve worked at McDonald’s say their local restaurants tried out menu items like grilled cheese, fried chicken, “hard” ice cream and even home delivery.
Did you know that McDonald’s once even tried to sell pizza? The Harvard Business Review explains what happened:“When McDonald’s attempted to offer pizza, for example, it assumed that the new offering was closely adjacent to its existing ones, and thus targeted its usual customers. But the project failed, and a postmortem showed that the launch had been fraught with risk: Because no one could figure out how to make and serve a pizza in 30 seconds or less, orders caused long backups, violating the McDonald’s service-delivery model. The postmortem also revealed that the company’s brand didn’t give ‘permission’ to offer pizza. Even though its core fast-food customers were demographically similar to pizza lovers, their expectations about the McDonald’s experience didn’t include pizza.”
Now, you might be reading about all this trial and error and thinking McDonald’s is grasping at straws—but that’d be the wrong conclusion. In fact, these kinds of small, localized experiments—even when they prove “unsuccessful”—signal a company interested in growth and innovation.
These defunct menu items may look like failures, but they’re actually extremely valuable data points in the company’s risk portfolio. Testing new offerings with customers on a small, iterative scale can help identify new market opportunities before investing too heavily, and can provide a deeper and potentially more lucrative understanding of what customers want.
McDonald’s failure, in the case of the pizza, was that it assumed it knew what its customers wanted.What’s the Job of an Egg McMuffin?
Noted Harvard Business School professor Clay Christensen, who introduced the concept of disruptive innovation, tells the story of working with an unnamed fast food company that wanted to boost its sales of milkshakes. The company had done marketing research in the past, only to make changes to its products that didn’t actually improve sales. So Christensen’s group took a different approach: they spent hours in the company’s restaurants, asking customers on the way out why they’d purchased their milkshakes. Here’s what they found:
- Forty percent of customers purchased their milkshakes in the early morning (for breakfast.)
- Many of them had long commutes to work and wanted to consume something that would last the whole ride.
- Customers wanted food that would fill them up and tide them over until lunch.
- The ideal item could be prepared quickly, to-go, was easy to hold and wouldn’t create a mess on their work clothes.
Christensen calls this approach to customer discovery “Jobs to Be Done” (JTBD), and the idea is that customers “hire” a product or service to fulfill a particular “job.” This approach is credited with breaking the mold of traditional marketing research (which segments customers by demographic slices and product categories) by uncovering the “true” intention behind customers’ buying behaviors.Give the People What They Want
It’s probably relevant that McDonald’s current CEO, Steve Easterbrook, took over the company after serving as its global chief brand officer, where customer sentiment was likely top-of-mind. Over the last year Easterbrook has focused on boosting perceptions of the company’s food quality—switching to cage-free eggs and removing antibiotic-fed chickens from the supply chain.
On its latest earnings call, Easterbrook noted that the company is using "forensic analytics " to respond to changing demand and buyer behavior, saying, "We are making improvements that our customers are noticing to serve hotter, fresher food with improved overall service experience."
So it’s not implausible to think that McDonald’s finally implemented all-day breakfast because it knew that’s what customers wanted. On the other hand, maybe those logistical hurdles it anticipated in its kitchens weren’t insurmountable after all. In fact, it’s quite likely that the company knew all-day breakfast was a worthwhile tradeoff, because this time—instead of making assumptions about what customers wanted, or would accept from its brand—McDonald's tested it first.Copernicus, Meet Customer
Business is all about the customer these days, in case you hadn’t noticed. Forrester Research, Inc. has declared that we are firmly in the “age of the customer … a 20-year business cycle in which the most successful enterprises will reinvent themselves to systematically understand and serve increasingly powerful customers.”
Forbes columnist Steve Denning, who writes frequently about agile, has described this shift as a kind of Copernican revolution: much like the original one, in which our previous understanding of the sun’s orbit around the earth was challenged by a new truth, previous beliefs about company dominance have been put to rest by evidence showing the customer is the sun around which we, the companies, now orbit.
(image via Forbes)
What this means is that attention to the customer experience is no longer a competitive differentiator; it’s table stakes.
If you haven’t already put your customers at the center of your business, it’s time. Is your business set up to deliver value to customers? Ask yourself these questions.
- Are you using “job”-based / JTBD interviews to find out why customers really buy your products and services … or don’t?
- Are you “getting outside the building,” doing ongoing customer development in your customers’ native environments?
- Are you using agile methods to speed up delivery cycles and get critical customer feedback, earlier in your development process?
- Are you leveraging UX designers to optimize your product’s user experience?
- Are you tweaking your management structure so that front line employees can better deliver and act on customer feedback?
- Are you using your Net Promoter Score as a key business metric?
- Are you taking an Enterprise Lean Startup approach to innovation, running small, localized experiments to test your ideas with customers?
Is all this focus on customers working? Well, McDonald’s customer satisfaction scores are up six percent from a year ago, and you already saw evidence of the turnaround in its recent financial performance. And in the age of the customer, as a restaurant research analyst recently opined,“Any move that gives your customers what they want, when they want it ... is a strong and positive move.” Jenny Slade
In a recent workshop, a participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in What Does Agile Mean to You?)
I suggested this could be his working definition:
- You can deliver what you want (some form of value).
- You can deliver that value when you want.
- You can then change to the next most important chunk of valuable work.
- You learn from the previous work you did, both about the work and the process of doing the work.
That’s not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)
These are practices that increase your agile capabilities:
- Iterations, because they limit the work a team can commit to in a given time period.
- Kanban with work in progress limits, because they limit the work a team can do, and show the flow of work.
- Retrospectives because you learn from previous work. (Someone important said if they only did one practice it would retrospectives. I can’t remember who said that. Sorry.)
- Standups because they reinforce micro-commitments to finishing work.
- Technical excellence practices from XP, because they make changing the code and tests easier.
You don’t need any of these to be agile. They help. You might find other practices to be more helpful in your context.
I have some previous posts that might be interesting if you also are wondering what agile means for you:
- Self Assessment Tool for Agile Maturity
- Agile is Not a Silver Bullet
- Agile is Not for Everyone
- Agile is about cultural change. See Stuck in the Middle of Your Agile Transformation, Part 3 for a series I wrote earlier this year.
For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.
Many of you will already be familiar with the Galactic Empire (spoiler alert: we’re the ones ruling the galaxy through fear and intimidation). It’s really great to have this opportunity to share some of my experiences in the challenging but rewarding field of galactic domination and demonstrations of hitherto inconceivable power and destruction.Approaching Agile Like a Master
Our releases are pretty mammoth. Like 120km mammoth in the case of our Death Star, and it’s the Death Star I’d like to discuss with you in this article. Not a lot of people know this, but the DS-1 almost never got completed and in fact could have been DESTROYED had we not discovered–and repaired–a small but nonetheless major flaw in our design. More on that later.
You may think that building a Death Star is as simple as welding together a few million panels of metal, wiring up some electrics, adding a few light fixtures and firing up the wireless router. Let’s put that myth to bed right now: Death Stars are a logistical nightmare. They are absolutely no fun to build, at any stage. They are pretty much financial suicide and include countless concerns and protocols, not to mention the amount of hardware and software development required.Death star specs (thanks Wookieepedia)
Most of these needs have to be outsourced to contractors across the galaxy, adding even more complexity to the logistics of the project. Several times I almost lost my mind trying to keep track of everything. Folks, I’m not exaggerating.
It’s also worth noting (and I’ve mentioned this before) even a technological terror of this magnitude is insignificant next to the power of the Force. Don’t ever be too proud. Be prepared.
An omnipresent threatening force is a useful methodology, but myself and my master, Emperor Palpatine, soon came to the realization that a more pragmatic, controlled and proactive approach to our project management was needed to pull off such a monumental and complex venture in a timely manner.
Of course, we adopted an Agile approach. But agile is not in and of itself the solution to complicated projects – it needs to be implemented well.
Thank the Force we discovered Axosoft to implement our agile workflow! Here are just a few ways in which certain Axosoft features helped us see some exciting (and some less so) aspects of Death Star planning through to completion:Planning Releases Releases
We needed to have the ability to plan our releases, both as a way of planning projects within the overall scope of the Galactic Empire’s continuing dominance of the galaxy, but also within each project.
We were able to plan with a forward-thinking methodology (we might, implausible as it may seem, decide to build another Death Star, for example) and also split up our Death Star progress into sprints to ensure milestones were clearly defined and completed on time.
Many subsequent tasks were dependent on completion of our defense systems, and so our shield and defensive firepower planning and construction formed our first sprint, with subsequent sprints being populated with items contingent on that security being in place (offensive weaponry and phase 2 of actual construction are two obvious examples).
Other items could run concurrently across multiple sprints, such as Human Resources policies, onboarding processes for certain staff members (but not others), etc.Viewing Backlogs Just some of our backlogs
The overview of our backlogs was essential for us to be able to glance at outstanding and completed items, see what priorities needed addressing, and filter down into a narrower selection of items. Using workspace tabs, we were able to filter items by designation, by sprint, and all sorts of other ways, and then save these views in convenient tabs at the top of the screen.
Within the DS-1 version (essentially our project), we added sprints to understand where in the overall project certain milestones would occur and what needed to be completed to meet them on time. For example, we were able to work out precisely at which stage in development the Death Star’s weapons and shields could be fully operational, even before overall completion.
Using Axosoft’s Release Planner, we were able to quickly drag and drop items to assign them to team members, and set up our releases.Burndowns and Dashboard
Work progressed and we amassed more data as workers entered in work logs. This allowed us to compare projected work hours with actual hours and identify where we were underestimating the time that items would take. We could then, at a glance, see how many hours each team member had available and could see whether members were overstretched or underutilized.
For example, as the development of our laser was completed ahead of schedule, we were able to reassign several scientists and engineers to the more menial task of uniform design and stitching, which was behind schedule. We were able to see at a glance that our workforce in this area would have been way overstretched, and so we made a polite request that others become team players.
After all, showing off the destructive power of a planetary deathray hardly looks impressive when conducted in the standard issue Empire polo shirts and khakis.
We used the snazzy burndown chart and dashboard to analyze this data and predict our completion dates. From there, we could make adjustments as necessary to get back on schedule.
(As an aside, this has become far easier to enforce now that the Death Star can destroy your home planet if you underperform. Nothing like the obliteration of your entire world as motivation to try just a little harder, is there?)Standup Mode
This was a big one, especially for the higher-ranked members of the team. Previous face-to-face standups had the unfortunate tendency to create situations where emotions ran high. Colleagues would always overrun or deviate from the discussion at hand, and this would lead to raised voices, sarcasm, and eventually force chokeholds from yours truly. In standup mode, we were kept to task, and things were, well, less disturbing.Daily standups used to get a little out of hand. Wiki
Axosoft’s wiki feature allowed us to collaborate in a sensical manner on certain items–mainly documents. We were able to set up items, and then link them (see the above screenshot) to their corresponding wiki for collaborative review. So, in the above example, we worked on a wiki to agree on content, logo usage etc.:
And ended up with a robust and efficiently-edited performance review form (go ahead, download it):
Literally. Using Axosoft helped us to better share updates, understand and anticipate the progress of every team, and adjust quickly to accommodate any unexpected changes.
Our burndowns let us see where scope had changed. We were able to see a timeline of comments and progress, and re-assign tasks as necessary to have a clear picture of who was responsible for what at every stage of an item’s progress. This was especially important re: a small issue that turned out to be pivotal in our balance of power in the galaxy.
A small vulnerability in our exhaust port seemed minor at first, but just the right shot could have DESTROYED the Death Star! (can you imagine the egg on our faces?) Axosoft allowed us to track our defense items much more robustly, and we were able to discuss issues and ensure no rash decisions were made (or ignored) without the review of other team members. We were able to act swiftly and with a clear chain of command to implement fixes.
Long story short – the flexibility that Axosoft afforded the Galactic Empire during the Death Star’s construction meant that the old plans stolen by the Rebel Alliance were not quite – ahem – accurate anymore.Nice try, son, but your plans are out of date! LOL
We had completed ahead of schedule but had also managed to squash a fair few bugs and design flaws that might otherwise have slipped through the cracks. Flash forward to the Battle of Yavin, the Rebel Alliance thinks we’re vulnerable – SURPRISE! – we’re not! We win the battle, crush the Rebellion and the Death Star shines on as a symbol of fear and tyranny throughout the galaxy. Pretty certain that’s how it went down.
Good times! Anyways, if you’re ready to cross over to the agile side, give Axosoft a try! xoxoxo -DV
Hey you! Are you working through some issues but don’t have time for the therapist’s couch? When you sit down and start working with the merge tool in GitKraken, all your internal struggles will disappear. No hypnosis or guided imagery needed.
Because the fact of the matter is conflicts are pretty common—in coding and in real life. And sometimes you need a referee, a parent or a therapist. Enter GitKraken’s merge conflict tool. It’s like having all of those three people in one.Here’s the Deal
According to Jose Garcia, Developer at Axosoft, “When you try to merge files or branches together you’ll occasionally get conflicts,” which in the past would force you to get out of your Git client, open another app, etc. Essentially, you have to take a bunch of extra steps.
Well, not when you use GitKraken! “The GitKraken merge conflict tool lets the user combine code the way he or she wants,” explains Garcia.
“Most Git clients ask you if you want to install another app. GitKraken will ask you, but also provides a way to resolve the conflict right in the app.”
According to Garcia, “One of the main goals of GitKraken is to keep users in the app so they don’t have to leave it to do things they should be able to do in GitKraken.” He goes on to explain that in order to do this, redesigning the UI was paramount.
“We had to make a custom area,” he reports. “There are three small windows that show you three different versions of the same file; so if you scroll through one, you want the other two to do so as well,” he explains. “We added that synchronization functionality.”The merge conflict tool performs in-app. Using the Merge Conflict Tool
It’s pretty straightforward, really. When you have a merge conflict, simply click on the conflicted file. Instead of opening the regular diff view you’re familiar with, it will open a specialized view for helping you resolve merge conflicts without having to leave the app.
This view has three different sections:
- The two side-by-side sections on the top half show you the different versions of the file you are trying to merge.
- The third section on the bottom half shows the output.
To select which lines you want to take, you can click on any individual highlighted line to add it to the output. You can also use the checkbox next to each conflict section to add the entire chunk to your output.
You can also just decide to take an entire side with the “Take All” button. The arrow buttons help you quickly navigate between the different conflicts in the file.
When you are happy with your selections, click on “Save and Mark Resolved” to save your file and stage it.
Check out the GitKraken release notes for more details about the merge conflict tool; it’s just another step toward making GitKraken 100% standalone!
Cross-functional teams are a set of people (and sufficient tools) that have all the abilities to produce a complete increment of work. Cross-functional teams can self-organize to figure out the best way to complete that work.
I call great cross-functional teams gravy because I grew up in the south and well, we put gravy on everything. An adaptable team can do a variety of things well. So Just like gravy you can pour them on mashed potatoes, but also the fried chicken too! It doesn’t mean we have cogs, but it does mean that they can adapt over time. They help each other overcome obstacles and they do it through learning and being intentional about where they are improving.
When turning a traditional team into a Scrum team, you get a bunch of people that have very specific roles. BA’s, QA automation, QA testers, UX engineers, Service Engineers, etc.
Waterfall methodologies, as they are implemented in most organizations, incent a person to stay in their specific lane. BA’s do requirements, QA manual testers manually test, and so on. There are a high number of specialists that go deep into their craft.
When you turn those same people into a Scrum team, the incentives change. The people on the team are incentivized to be cross-functional so that roadblocks and bottlenecks are cleared rapidly.
Here’s how I start off new teams when they begin Scrum.
First, we do need some specialists. Not everyone will automate everything, not everyone will know the corporate security protocols. This needs to be acknowledged. It’s not about going to an extreme edge where everyone can do everyone else’s jobs.
Second, it is about bottlenecks. During the task breakdown section of sprint planning, I horizontally map the workflow of the team to the stories they are trying to complete using sticky notes. I find it best to walk backwards from production. How do you promote to production? Did anyone do it for you? Are they on this team or is that a dependency? What about regression? Etc. I do this all the way back to the origin of the work for a new Scrum team.
Next, I ask the team to put their names under each state for what they could possibly do. I will ask them to elaborate on the ability they need to complete the task, (i.e. Java).
Once that is done, we can identify bottlenecks. A certain person may be the only person that can perform a task. If they are out, the team has to wait. That person needs more slack in their personal system so that they are never causing the team to wait.
In order to overcome this, the team can decide if the bottleneck is important enough to cause them to generalize. They may pick one or two members to learn that ability so that the team can remain adaptable in the face of change. The team needs to consider what to change instead of going all in and trying to become generalists on everything. This method causes the visualization of bottlenecks, skill sets, and will unbury hidden treasure (skills) in the team’s system. The team can then prioritize and tackle the solutions that will make them faster with the same or higher level of quality and really internalize the fact that they are a team. From there, it’s all gravy.