Three Things You Need to Know to Transform Any Sized Organization Into an Agile Enterprise #agile2015
Here is my talk from this AM at the #Agile2015 conference. Enjoy!
The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise from Mike Cottmeyer
The post Three Things You Need to Know to Transform Any Sized Organization Into an Agile Enterprise #agile2015 appeared first on LeadingAgile.
Rally customers have always been front and center at RallyON conferences — filling the audience and the speaking agenda with their experiences, knowledge, and ideas. But at this year's RallyON 2015 conference, our customers were so engaged they nearly blew up the conference app. Since their commentary did such a great job of capturing the essence of what we heard and learned at RallyON, we thought we'd share a few of the conference’s customer stories about Agile at scale — in our customers' own words.The Seagate Story
Seagate is a leading producer of data storage solutions. To keep up in this industry, Moore’s Law alone dictates that you have to move fast. Seagate knew it needed a better way to predictably and reliably get products out the door, but it wasn’t initially familiar with Agile approaches.
At RallyON 2015, Seagate Agile coach Iky Chan and Rally Solutions Architect Andy Carlson co-presented a talk on Seagate’s journey from a waterfall shop to one that now assembles all 100+ members of its firmware group for release planning on a regular cadence.
Their story starts out describing how Seagate worked up from piloting a few Agile teams to selling leadership on the first big room planning event.“What is big room planning? It's mid-range planning with all the people connected to a value stream. You need to get more than 7 plus or minus 2 people in a room together if you want to solve complex problems."
As the main ceremony for an Agile delivery group to successfully deliver on its release, big room planning naturally requires an investment of time, energy, and preparation. The Seagate talk did a great job detailing and demystifying the process of running a big room planning event. Chan even included a photo of her “big room planning suitcase.”
“Prep is required for a successful big room event.” "What’s in your big room planning kit? Big Post-Its, Sharpies, tape, markers, snacks . . . What else?” “Big room planning is often scary and intimidating — the first time! Each time it gets easier and easier.”
Halfway into their talk, Carlson and Chan put up a photo of several developers looking at a whiteboard full of stickies, an intimidating “wall of WiP.”
The success of Seagate’s investment in Agile might be summed up in this quote:“These guys used to work weekends. Since they started big room planning, not anymore. #bigroomplanning helped Seagate address bottlenecks and become more predictable.”
Several audience members noted during the Seagate story that big room planning isn’t valuable just for the work it produces, but for how it brings people together to collaborate:“The outcome of big room planning isn't just a plan. It's a group prepared to execute on a plan.”
Chan closed the talk by exhorting the audience to “run, don’t walk” to the scaling agile booth in the lobby, where we demo’d how Rally’s new features can be used to improve your release planning.
When PayPal VP of Technology Kirsten Wolberg opened her keynote about PayPal’s Agile transformation, it made #BigBang a trending hashtag.“If we didn't do a #bigbang the fear was we'd get all of the pain and none of the benefit because there were simply too many dependencies.”
As with many transformations, PayPal went all-in on change because its status quo had become untenable. A system of 15,000 people, left to its own devices, had devolved into bottlenecks and a lack of trust. There was too much effort on projects with not enough output, so the company committed to unraveling its problems and fixing them.“Learning about the ‘why’ is important so that you can figure out the ‘what’ when it comes to transformations.” “Transformations usually are not about the development process. They are about mindset.”
Wolberg pointed out that executive support — a vital component of any transformation — isn’t the same as buy-in. Case in point: she heard,"I trust you, but think you will fail spectacularly."
Executive support means leaders may not agree with every aspect of a transformation, but they will stand behind you to make change happen. She commented that leaders at every level need to play together for successful transformation: a mature leadership team has a willingness to look for and find problems, for example, then listen to advice about how to fix them.
As Wolberg describes in her keynote, PayPal mapped out a seven-month change agenda with four key pillars:
- Customer-driven innovation (CDI.) “Let’s figure out what the customer wants, not what we want.” This meant talking to customers, walking in the customer’s shoes, to understand their problems. This is in contrast to “executive-driven innovation,” which, as Wolberg said, has a greater chance of missing the mark since executives typically are not “in the same headspace” as customers.
- Core product operation model. PayPal implemented a product model centered around core product teams providing basic functionality (the “chassis”), with regional teams customizing for local needs. This approach was introduced to foster alignment and focus around core products (working on the right thing at the right time), while eliminating unnecessary complexity.
- Agile transformation. PayPal made a concerted effort to build Agile teams and ensure they had strong Agile practices. They re-organized teams — who previously had been siloed in 83 different product groups — around a vastly smaller set of value streams. In the process of assembling Scrum teams, they actually identified 200 “missing” people. And they gave teams ownership of the products, which fostered a sense of “having skin in the game.” Additionally, PayPal enlisted coaches in every region to provide back-up and support so teams could focus on delivering their work.
PayPal gave its Agile teams lots of flexibility, but asked every team to adhere to just two clear rules: follow a synchronized sprint cadence (start and finish sprints at the same time) and use a single, shared platform (Rally) for tracking work. There were knowing chuckles in the room as Wolberg described the fervor with which teams can get trapped in the "tool debate" — when the real challenge of an Agile transformation isn’t a tool at all, she pointed out, but resistance to change.
KPIs. Key Performance Indicators are vital, explained Wolberg. Product and technology teams need to be accountable, and if you don't measure the value of your actions you won't know if they’re working. In particular, the company was keen to measure engagement — which it believes can lead to better solutions and better quality.
There were nods around the room as Wolberg called out middle management as most resistant to transformational change.“Permafrost, typically known as middle management, ice that never melts. Lol.”
She pointed out the importance of having open and honest conversations with development managers, to celebrate successes and identify opportunities, and called on us to use discipline in changing our own all-too-human behaviors.“You have to hear something 7 times to remember it, and you have to do something 21 times to make it a habit. (Very true! )”
Wolberg ended her talk by summarizing some lessons learned at PayPal, and our customers in the audience had their own a-ha moments:“The value of portfolio planning & roadmapping … Agility is a top-down mindset.” “Forming teams around the work/product is more effective than forming teams around the organisation chart.” "Fundamental agility disciplines and practices need to be built into the workflow; they are vital to moving forward well.”
The Physicians Mutual Story
Physicians Mutual, an insurance company that’s been in business for more than 100 years, makes its headquarters in Omaha, Nebraska. So it seemed fitting when Physicians keynote speaker — Project Manager and Certified ScrumMaster Joan Bohannon — cited the famed Omaha businessman Warren Buffett near the beginning of her talk."Great quote: ‘Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.’" “All hail the Oracle of Omaha!”
Like PayPal, Physicians told the story of a pilot turned #bigbang Agile transformation; but that wasn’t initially how its Enterprise Technology Group got started. The group had been using RUP and waterfall approaches before piloting Agile methods, and its first attempt at Agile adoption failed — for reasons that seemed all too familiar to some in the audience:“The usual story ... No team, process or product integration … this is pain! Lack of integration creates bottlenecks and dependencies!” “[They] did Agile with one or two teams and one or two projects, but it didn't become sticky; Did Agile 101 training, but not role-based training." “Limited roll out = limited results.”
So the group took a deep look at how it was doing things, and decided to make some serious changes — cue Warren Buffett’s advice to get a new vessel rather than patch the leaks. At Rally we often talk about transformational change through platform, process, and people, and Physicians set out to improve all three of these areas.
Platform. Like many growing companies, Physicians had integrated various technologies in an effort to harness its growing complexity — only to end up with a vast (and complex) catalog of tools. When it overhauled its catalog and settled on Rally as its central hub, Physicians went from 23 different tools down to 5, at a savings of $300,000. “We looked at many tools,” said Bohannon, “but we quickly realized that Rally was the only organization that could provide training and coaching as well as the platform we needed.” Standardizing on a single platform had other benefits, too:“As soon as the software got in the door, people were so excited about it that they didn’t want to wait for the pilot. that’s when we realized we should be going with a big bang approach.”
Process. "Boy, did we have process,” said Bohannon. “Click on any one of these and you'll get more process," she said, standing in a front of a slide with a spider web of interconnected people, departments, and requirements.
Physicians actually reviewed all of its legacy processes and got rid of the ones that weren’t working, leaving them “just enough process to be successful.” With the Rally platform in place Physicians can plug directly into its other four tools, further minimizing process maintenance and context-switching.“Rally integrations streamline processing!” “I envy having five tools.”
People. Unlike the first time around, when it only did “intro to Agile” courses for some pilot teams, Physicians was keen this time to include comprehensive and role-based training — as well as Scaled Agile Framework® (SAFe®) training to help them implement and manage the transformation. “We trained everyone,” said Bohannon. “Project managers, testers, developers … and we coached some in-house coaches to provide ongoing support.”“Very impressive investment in people!”
With the platform, process, and people changes in flight, Physicians began to use its Rally data for conversations about performance and collaboration. Rather than seeing metrics as a weapon or punishment, the increased transparency helped teams drive important discussions — “the why behind the what.”“Early conversations allow course corrections. Late conversations can become screaming matches!” “Transparency for team health checks - what a bonus!” “Rally helps provide transparency for end to end process improvements. Love this!”
One of the early conversations at Physicians was about estimates, points, and timesheets. Physicians made an effort to move away from timesheets and learn to estimate and plan based on points, instead. At a business level, cost by points turned out to be more accurate than timesheets — whose value was questioned by many in the audience:“Timesheets are a drag! Wow!” “??? Could this ever work for our organization ???”
Physicians uses Rally and Planview for its portfolio planning and management, and Physicians Program Manager and co-keynote speaker Thomas Hall described how its product owners and portfolio managers plan and track progress — from the team level to the program level to the portfolio level.
Hall explained that portfolio management is hard, but critical for enterprise success. A “Business Council,” comprised of senior executives, is charged with setting strategic priorities for the company. Portfolios steer the business to the highest-value priorities; programs align the development work to those business priorities; and delivery teams plan and track their work according to program direction. Feature definition is key to successful prioritization. Product owners gather as a team to review and assess. When estimates change, that information rolls back up the hierarchy so they can re-evaluate the plan.“Business council is the way to go! Keep the enterprise focused! Realise the value stream! Love this!”
Because everyone in the group — from developers to executives — is using the same platform, they can all see progress in realtime and make necessary adjustments. Teams have access to important information about prioritization and capacity, while managers can identify risks and do more accurate planning.“Would love to get out of Excel and PowerPoint and into Rally.” “My program managers are not looking at this sort of detail. It would really up the game. A cool view to assess the health of the backlog.”
In addition to decreasing its tool footprint and maintenance costs, Physicians’ Agile transformation has yielded other substantial benefits: the Enterprise Technology Group has increased its major releases from four to six per year, and now delivers at the end of every iteration — nearly 1,000 stories per year — without waiting for a major release. More importantly, given it’s the group that maintains the entire company’s business-critical systems, it has improved its ability to respond faster to market demands and is considered a trusted, predictable partner for the business. Customers sure loved the outcome.“Great insights from actual practitioners!” “Big Bang approach to agile transformations hurts my head, but I'm thinking it through …” “Love the hard conversations this will evoke!”
Want more stories? Check out some of our other scaling Agile customer stories from RallyON, including another perspective on Physicians Mutual’s transformation, “What Pilot? Physicians Mutual's ‘Big Bang’ Approach“; “Scaling Scaled Agile: Lessons Learned at UnitedHealth Group” and “Heartland’s Scaled Agile Journey.”
YbSync is a tool that allows users to connect their Google Calendars to Axosoft and keep them in sync. YbSync has a lot of options that allow users to configure how ybSync syncs your data: choose which Axosoft items get synced with Google Calendars and choose to have notifications added to your Google events. Administrators have the ability to set up default syncing options for the rest of their users. Users always have the ability to change the default options.
In this post we will demonstrate how to get started with ybSync, and we’ll walk you through the following steps:
- Enable API access in Axosoft
- Create a ybSync account
- Connect your account to Axosoft
- Connect your account to Google Calendar
- Configure your account to synchronize data
- Add a Google notification to Due Dates for Bugs.
The first step is to enable API access to your Axosoft account. YbSync will use the Axosoft API to read your Axosoft data. Log on to your Axosoft software as a user with admin privileges and select Tools -> System Options from the menu.
Click on the Axosoft API Settings on the menu on the left.
Click on the Enable API check box if it is not already checked. Axosoft API access is now enabled.Create a ybSync account
The second step is to create your ybSync account. To create your account click on the Create Account link from the ybSync.com homepage.
Fill in the form and click the register link.Connect your account to Axosoft
Next you will need to connect to Axosoft.
Enter the URL of your Axosoft application and click the Connect button. The URL if often something like https://COMPANY-NAME.axosoft.com.
You will be prompted to sign in to your Axosoft account.
Enter your name and click the “Sign In” button.
After successfully signing in, you will be asked to grant ybSync read only access to your Axosoft data. Click the “Allow” button.
After granting ybSync access to your Axosoft data, you will need to let ybSync know which Axosoft user to connect your account to. YbSync gives you the option to only sync items that are assigned to you. When this option is used, ybSync uses this account to determine which items to sync. The “Is Admin” checkbox is checked because the first account created for a company is always an administrator. The administrator is allowed to create users for the company and to pay for user licenses. Active users count toward a company’s user license count. Inactive users’ data is not kept in sync. “Sync Data” allows ybSync to sync your data. If you deselect this check box your data will not be synced. You can also turn this on and off on the dashboard.
Select an Axosoft User and click the save button.Connect your account to Google Calendar
The next screen tells you that the next step is to connect your Google Account. YbSync needs access to your Google Account to add calendar entries.
Next you will choose a google account. Log in or click on the account you wish to sync with Axosoft.
The next screen allows you to manage your google settings. You can select which calendar you want to have ybSync use. You can also select the color of the entries that ybSync creates for you. Select your calendar and calendar color and click the save button.
This is your account dashboard. A trial account has been created for you with three users. The trial lasts for 14 days. The top of the dashboard tells you that your account is scheduled for syncing. You can turn off syncing by clicking the “Turn off Syncing” link. The Axosoft account section allows you to change the URL of your Axosoft software. The Google account section allows you to change which Google account ybSync uses and to change the color of the entries ybSync creates for you. The ybSync Plan allows you to modify the number of licenses you have. YbSync uses Stripe to process its payments. Manage users allows the administrator to add new users to the accounts after user licenses have been purchased. Manage User Settings allows you to manage what Axosoft data gets synced to your Google calendar. Manage Company Settings allows you to set up the default user settings for new users added to your company. New users will be created with copies of the user settings created in the Manage Company Settings.
Only administrators have access to the Axosoft Account, ybSync Plan, Manage Users, and Manage Company Settings features.Configure your account to synchronize data
The next step is to configure which Axosoft items get synced with the Google calendar. Click on the “Manage Sync Settings” link under the Manage User Settings heading in the dashboard.
Your sync settings are broken up into the three types of items that Axosoft manages for you. The names of the items may be different from yours because the names are configurable by your Axosoft administrators. The first check box for each of the items tells ybSync to only sync items that are assigned to you. Items that are not assigned to you or not assigned to anyone will not be synced if this check box is checked. The rest of the check boxes allow you to pick which dates get synced to your Google calendar. Clicking the save button saves your changes. Your changes will be reflected the next time the ybSync engine runs.Add a Google notification to Due Dates for Bugs
The last thing we will do is to configure ybSync to create Google notifications for all bug due dates. Navigate back to the Dashboard by clicking “save” or “cancel” on the sync setting page or via the Dashboard menu item on the menu bar.
Click on the “Manage Google Notifications” link in the Manage User Settings section of the dashboard.
This is the screen that displays your Google notifications and allows you create new notifications and edit or delete existing notifications. To create a new Google notification click on the “Create New Link” near the top of the screen.
You have the ability to create notifications for each of the different Axosoft fields that you can sync with ybSync. The first drop down on the page allows you to select which Axosoft field you would like to create a notification for. Selecting “Bug Due Date” tells ybSync that you would like to have a notification created for each calendar entry that ybSync creates for bug due dates in Axosoft. “Days before” tells ybSync what day to create the notification on. When days before is 1, ybSync creates a notification for one day before the date of the calendar entry. “Notification Time” is the time of the notification. There are two methods of notification: pop-up and email. Clicking on the “create” button creates the new notification. YbSync will create new notifications the next time the sync engine runs.
You will notice the new Google notification entry has been created. Clicking the “delete” link allows you to delete a notification, and clicking the “edit” link allows you to edit a notification.Summary
This post has shown you how to enable API in Axosoft. We created a ybSync account and connected it to Axosoft and our Google calendar. We configured ybSync to sync the data from Axosoft that we wanted to have synced, and we configured ybSync to add a notification for all bug due date entries.
You can learn more about ybSync.com at our blog.
It’s hard to imagine that we’re celebrating the 10th year of the State of Agile™ survey! The annual survey has become the largest, longest-running, and most comprehensive survey serving the agile community.
Last year nearly 4,000 of your peers shared what they’ve learned through their agile experiences. The survey gives agile software professionals around the world the opportunity to provide insights on a wide range of agile topics including the benefits of agile, top tips for scaling agile, how to measure agile success, and the most popular agile project management tools. This year we will be conducting an even deeper analysis of the trends over the past 10 years.
To help celebrate the 10th anniversary, VersionOne is giving away 10 Apple Watches in a random drawing in each of the 10 weeks that the survey is open. The survey, which takes about 10 minutes to complete, is open until Oct. 2. The full report will be available in early 2016.
For the past nine years, the results from the State of Agile survey have been helping organizations realize the benefits of agile faster, easier and smarter. Help the agile community make the 10th annual State of Agile survey the most valuable report yet!
State of Agile is a registered trademark of VersionOne Inc.
In agile, we separate the Product Owner function from functional (development) management. The reason is that we want the people who can understand and evaluate the business value to articulate the business value to tell the people who understand the work’s value when to implement what. The technical folks determine how to implement the what.
Separating the when/what from how is a great separation. It allows the people who are considering the long term and customer impact of a given feature or set of features a way to rank the work. Technical teams may not realize when to release a given feature/feature set.
In my recent post, Product Manager, Product Owner, or Business Analyst?, I discussed what these different roles might deliver. Now it’s time to consider who should do the product management/product ownership roles.
If you have someone called a product manager, that person defines the product, asks the product development team(s) for features, and talks to customers. Notice the last part, the talking to customers part. This person is often out of the office. The product manager is an outward-facing job, not an internally-focused job.
The product owner works with the team to define and refine features, to replan the backlogs, and to know when it is time to release. The product owner is an inward-facing function.
(Just for completeness, the business analyst is an inward-facing function. The BA might sit with people in the business to ask, “Exactly what did you mean when you asked for this functionality? What does that mean to you?” A product owner might ask that same question.)
What happens when your product manager is your product owner? The product development team doesn’t have enough time with the product owner. Maybe the team doesn’t understand the backlog, or the release criteria, or even something about a specific story.
Sometimes, functional managers become product owners. They have the domain expertise and the ability to create a backlog and to work with the product manager when that person is available. Is this a good idea?
If the manager is not the PO for his/her team, it’s okay. I wonder how a manager can build relationships with people in his/her team and manage the problems and remove impediments that the team needs. Maybe the manager doesn’t need to manage so much and can be a PO. Maybe the product ownership job isn’t too difficult. I’m skeptical, but it could happen.
There is a real problem when a team’s manager is also the product owner. People are less likely to have a discussion and disagree with their managers, especially if the organization hasn’t moved to team compensation. In Weird Ideas That Work: How to Build a Creative Company, Sutton discusses the issue of how and when people feel comfortable challenging their managers.
Many people do not feel comfortable challenging their managers. At all.
We want the PO and the team to be able to have that give-and-take about ranking, value, when it makes sense to do what. The PO makes the decision, and with information from the team, can take all the value into account. The PO might hear, “We can implement this feature first, and then this other feature is much easier.” Or, “If we fix these defects now, we can make these features much easier.” You want those conversations. The PO might say, “No, I want the original order” and the team will do it. The conversations are critical.
If you are a manager, considering being a PO for your team, reconsider. Your organization may have too many managers and not enough POs. That’s a problem to fix. Don’t make it difficult for your team to have honest discussions with you. Make it possible for people with the best interests of the product to have real discussions without being worried about their jobs.
(If you are struggling with the PO role, consider my Product Owner Training for Agencies. It starts next week.)
Would you dare to make your software product as visual as Targetprocess? Or do you need just to visualize data, projects or certain processes to manage them more effectively?
In June-July 2015 we conducted a Customer Survey in order to understand our customers’ perspective on the key differentiators of Targetprocess as a tool to manage Agile projects. It was gratifying to hear that one of the key factors why the customers love Targetprocess is its visualization capabilities, i.e. the functionality it has for managing projects and various processes visually.
It was gratifying for us because it sounded like one big dream came true: we did want to enable people to see and to change things that are not visible on the surface or at the data level, but can be visualized for insights and actionable conclusions. That’s actually the motto of Targetprocess: “See. Change”.
Taucharts is still a young library but can be already used as a foundation for custom graphical reports. Check it out at http://blog.taucharts.com/taucharts-data-focused-charting-library/, try to visualize your data and get a bit closer to the bar set by Targetprocess for visual, more effective project management! ;-)
If you haven’t yet used Targetprocess, jazz up your project management, get a free trial account!
Sometimes, when I get ready to speak in front of a huge room of people, this little voice inside my head pops up and says. “Who do you think you are to be in front of these people? You don’t have anything all that insightful to say. They’re going to find you out. You will once and for all be exposed for the fraud you are.” It can get pretty harsh. Fortunately, that voice doesn’t pop up nearly as much as it used to, and when it does I know how to kick it to the curb.
One thing’s for sure, I’m not alone in this. Often, when I am coaching an agile coach or working with one in the classroom, they have trouble accessing answers to some of the questions I ask them. Questions like, “What are you proud of?” or “What needs to be celebrated?” It’s not that there is nothing to be proud of or to celebrate, it’s more likely that the person I am working with is dealing with a feeling of inadequacy that has them downplay or outright deny their successes. They’ll say, “Nothing.” Or, even a more insidious form of sidestepping, “I don’t understand your question. Could you rephrase it?” About the third time I ask a question like this and hear anything but what they did well, I start to wonder if the person is dealing with something called Imposter Syndrome.
It’s come up a lot lately. Perhaps many agile coaches are in the Imposter Syndrome pattern. Here’s what Wikipedia says about it:Imposter Syndrome is psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be. Notably, impostor syndrome is particularly common among high-achieving women. Interesting that the research calls out women. While that may be supported by some study or another, my experience is that it Imposter Syndrome just as active in men. In fact, most of my experience in coaching people through Imposter Syndrome has been with male agile coaches. The sample sizes are too small to draw a strong conclusion, so let’s not make too much of the gender angle. Let’s just say that anyone can fall into the Imposter Syndrome pattern.
I believe that it’s coming up so much in my students and coaching clients because the nature of working agile constantly throws us into new and often contradictory mindsets when compared to the dominant industrialized-mindset prevalent in so many of our organizations. It’s easy to feel like a fraud in this situation, made worse by the demands of an ever-increasingly complex world where it’s not clear what to do or even what success means. It can have even the most confident start thinking, “I’m not up to this. They are going to find out that I have no idea what I’m doing and then I will be exposed for the fraud I really am.” (or your favorite version of this sentiment) The difference is that the some will bounce back from this unwelcome thought while others will start to wallow in it, wading into the depths of Imposter Syndrome.
Here are a couple other tell-tale indications of Imposter Syndrome I see regularly:
Half-way through an agile coaching class I’m co-leading, invariably a student will come to me and ask, “What class do I need to take next?” They’re not even done taking this one, much less practicing what they learned! While I sense their urgent thirst for knowledge, most times when I ask a few more questions I start to see that the person in front of me is in acquisition-mode. Operating under the belief that if they just acquire more knowledge, more models, more ideas, more, more then someday they will know enough to feel like they are a real agile coach. That there will be some magical time in the future when they have gained enough knowledge to “arrive” and feel that they finally deserve the position they are in.
- A close cousin to the last, a question I often get asked is, “When can I call myself an agile coach?” This usually has nothing to do with the person’s experience or abilities. I get this question from people who have been working quite successfully with agile teams for 5+ years. If I’m feeling particularly cheeky, I might respond with, “How about yesterday?”
All cheekiness aside, I take Imposter Syndrome seriously. It has been a common companion to many people I’ve been working with. Imposter Syndrome can freeze up an agile coach in the belief that no matter what they try, there is always some way they should have known better or should have been better. It can also grind a coach down, because even when successful, the coach will chalk their experience up to “dumb luck”, not realizing that their success is actually due to skill and, therefore, repeatable. Finally, the constant pursuit of knowledge can have a coach act only from the information in their head, cutting them off from the powerful example their being can offer.5 ways out of Imposter Syndrome
1. Get coached. A professional coach is the most surefire way to keep Imposter Syndrome at bay. Many agile coaches now have professional coach training, so ask around. You can also find a straight-up professional coach through the International Coach Federation. Deborah Hartmann Preuss, an agile + professional coach, has also created a beautiful self-coaching book, You Can Design a Bigger Game.
2. Tap into the essence energy.The light side, or useful essence energy of Imposter Syndrome is bowing to the reality that one can never know enough for every situation coming down the pike; that being humble in the face of ever-changing complex situations can be a useful strategy. So instead of throwing the baby out with the bathwater when overcoming Imposter Syndrome, try incorporating this useful aspect while saying “no, thanks” to the dark side of Imposter Syndrome.
3. Get inspiration. How about having a source of inspiration at your fingertips? That’s just what I envisioned in the creation of the InspireMe! deck. It’s a selection of the 60 best inspiration emails I have ever sent, put into card form so you can have them at the ready when that Imposter feeling strikes. The cards offer a word of advice to help you take that next step, a reminder to stop and appreciate what is already going well (and insistence that you do so), or a challenge that spurs you into action. Through these cards, I am with you, on the days that you recognize your abilities and on the days that you start to think the Imposter has it right.
4. Access your inner superhero. I love helping people find their inner superhero, and have particularly enjoyed the #itwasneveradress movement which is aimed at empowering women in tech. Yes, this one is for you, ladies! Put on your capes and kick that imposter to the curb! And, everytime you go into the ladies’ room, remember that your cape is showing! Wear it proudly.
5. Coach others. For those of you proficient in professional coaching skills, and who coach folks working with Imposter Syndrome, you can find insight and many more professional coaching approaches in The Coach’s Casebook by Geoff Watts, agile and professional coach, and co-author, Kim Morgan.To men and women alike, let’s don our capes! The Agile world needs us to be fully authentic, which includes claiming the ways in which we are intelligent, competent, skilled, visionary, courageous and most of all…deserving.
I didn’t want the day to pass without noting LeadingAgile is celebrating our five year anniversary today. It’s super surreal to me that we have been in business for five years. It’s truly been the combined efforts of a very talented group of people that has gotten us this far.
I sincerely appreciate all the effort, of all the folks… both past and present… that have worked at LeadingAgile. I appreciate all the awesome companies that put their trust in us to help guide their agile transformations. It’s been a hell of a ride. Thanks for being a part of it.
Retro process phases: Set the Stage, Gather Data, Generate Insight, Decide what to Do, Close the Retro
Set the Stage: give time to “arrive” and get into the right mood and focus upon the goal
Gather Data: reflect upon what happened, create a shared pool of information
Generate Insight: why did things happen this way? What patterns can we observe?
Decide What to Do: Pick what to work on, plan concrete steps of action
Close the Retro: reflect upon the retrospective, how could it improve? What shall we follow-up upon?
Activities for this Retro:
In ONE word – what do you need from the retro?
In ONE word – what is on your mind?
In ONE word – what is you current mindset in regards to your project: are you a:
Explorer – eager to dive in and research what worked
Shopper – Positive, happy if 1 good thing come out
Vacationer – Reluctant, but retros beat regular work
Prisoner – Only attend because they make you
The Four Ls
Regarding the last iteration, individually for each of these 4 questions (one item per sticky) write:
What I Loved
What I Learned
What I Lacked
What I Longed for
Everyone rates the last iteration on scale of 1 (poor) to 10 (perfect).
Next – make suggestion to raise your rating toward a 10, rate that suggestion using remaining 10 – x points
Circle of Influence & Concern
On a chart of concentric circles… inner to outter circle;
Team controls – direct action
Team influences – persuasive action
System – response action
Sort insight from Perfection Game into circle of influence & concern;
Write possible actions – annotate the item with actions
Dot vote on which action to attempt
The team created this info graphic of their Four Ls exercise using the Circle of Influence & Concern. Stepping back they realized - they are the master's of their domain.
We Control our own Destiny
Feedback Door – Smilies
Happy, OK, Sad
Mark your satisfaction with the retro session on the chart.
How does a 120-year-old insurance company get more value out of its agile transformation in 2 years than a high-tech company that’s been practicing agile for 14 years? Well, it has something to do with bad habits that form when organizations don’t scale agile beyond the team level. Or they coordinate work to include the business and program management roles but don’t focus on best practices and continuous improvement to maintain results.
Here are some common traps organizations can fall into around team-level agile:The Easy Road
It’s human behavior to take the path of least resistance. In the context of agile, I’ve seen teams and delivery groups (even those that religiously do retrospectives) take the easy route to tackle a problem rather than take on time-consuming — and sometimes contentious — changes to improve how they work. This ultimately leads to technical debt, and worse, unhealthy agile practices.Developer-only Agile
The whole premise of agile is to connect the business and development to deliver value. Even in companies where strong development teams are killing it with agile, it’s pretty common for those teams to exclude outsiders. When that happens, teams start working in isolation, losing sight of what other teams and the business need, when they need it. Responsiveness, predictability and value delivered quickly become disconnected from market windows and what customers want. Organizations trying to retain valuable programming talent do the same thing — make decisions that keep developers happy instead of thinking about what’s best for their customers and the company.Managing the Matrix
Enterprises experimenting with agile often try it within existing organizational structures. While agile teams can exist that way for a while, more often than not they end up isolated and can’t consistently deliver the value that the company needs to win in the market.Developer Musical Chairs
Sustaining dedicated teams over time is key to agile success. When you start moving developers around to solve various problems that pop up, you create an extra learning curve, lower capacity and, sometimes without intending to, make decisions that can derail the features you’re trying to deliver.Unmanaged Chaos
Companies that start to slack off on disciplined agile practices (like Kanban and Scrum) end up with highly reactive environments. This creates hidden work, high levels of work in process (WiP), lack of focus and even purposeful focus away from the company’s vision. Teams feel helpless and frustrated because they’re constantly playing defense.Where Do You Start?
Sure, these problems can be overwhelming and prompt organizations to start questioning their investments in agile. But you can get back on track just by getting back to the basics.
Get back to basics. Re-establish great team-level practices (proper Scrum and Kanban), limit WiP and use metrics to help teams stay focused. Create value streams that follow the work, maintain dedicated teams and build strong delivery groups.
Adopt agile at scale. You won’t get to the next level of agile just by doing it at the team level — you need to launch a whole program right from the start. Organize for the work and find the courage to make your company structure part of the transformation. Create an agile center of excellence — and give it authority and funding — that guides the practices and evolution of your organization’s agile teams, delivery groups and people.
Include product and program management. Understand how to build a good agile roadmap and collaborate with your customers. Talk to them not only about what you’re currently delivering but about your future plans — and smooth the flow of work to teams so they’re working on the right things at the right time.
Invest in continuous improvement. Establish a culture of continuous improvement and support it with a mix of qualitative and quantitative measurements. Strategize collaboratively with big room planning that includes everyone in the delivery group. Watch how our customer, Seagate, uses big room planning to speed delivery, save costs and become a predictable engine for the business.Achieve 4x Improvement
Achieving the true promise of agile (4x improvement) comes by connecting the whole system (not just teams) and making sure you’re always transforming and fine tuning to guide your agile journey.
Remember those two companies I mentioned? By launching its agile transformation at scale from the get-go, the insurance company (the agile rookie), Physicians Mutual, saw a 50-percent increase in major release frequency and the delivery of hundreds of items during the course of just one year. Read the case study. I was directly involved in helping the high-tech agile veteran (Rally) get back to basics to achieve 2x feature output and deliver 100 percent on our roadmap commitments.
If you want to learn more about how to effectively scale agile in your organization, I’m hosting a “Next Level Agile” webinar on August 19 at 11 a.m. MST in the U.S. and 2 p.m. BST in the UK. Register here for the North America webinar and here for the EMEA webinar.Ryan Polk
Devs: when it comes to Axosoft, we want you to get in, get out, and back to doing your thing. You really only need to do three actions to contribute to your team:
- Log in
- Log your time
- Update workflow steps
The three actions above give your team a clear understanding of what’s going on. Allow us to break down these three lovely bullets further and get you on your way.Log In
You’re logged into your Axosoft account–yes! If this is your first time, then you’ll be prompted to take a tutorial (which we recommend taking). If you prefer to learn by experience, then you can also hit the red “Stop Tutorial” at the bottom of the screen.Press play in the app!
We do have a means to fast-forward this step if your team runs TFS, Github, or Tortoise SVN for source control (see the Source Control section below).Log your time
You just finished today’s work and it’s time to tell everyone how it went. Axosoft passes along this info in what we call a worklog, and it’s pretty straight-forward.
First, find your item and then use the keyboard shortcut “W” or access it from the “Details” panel. If you love the card view, click on the progress bar in any card to bring up the worklog window as well.Click the bar to jump to a worklog from Card View
From here, just communicate what you see and then save.Update your work with worklogs. PM’s really like this for some reason :D
If your team has copious amount of items, consider reviewing my bonus material on filters and views below to bring up those items every time you log in. TFS, Github, or Tortoise SVN users also get a worklog shortcut (again, see the Source Control section below).Update workflow step
Your team likely works in some series of steps or stages. Axosoft calls these processes “workflows,” which are comprised of workflow steps. For example, you might need to first place a bug in the “Verify” workflow step before you then move it to “In Progress” once it has been confirmed.
Whether or not this sounds familiar, updating the workflow step in Axosoft is a breeze. Most users either use this drop down menu or they just drag and drop the item into the next workflow step column. This is my favorite step, especially when I’m done with items.Use this dropdown menu for List View or Card view to change the workflow step.
There you go! By following these steps, you have provided the most crucial data for answering the question: when are we projected to ship? Now for the bonus material.Filters and Supertabs
Filters and Views are indispensable for finding your items within two clicks. For example, perhaps you want to create a View that shows only items assigned to you and that are not completed. Or, maybe you want a View that shows items assigned to you and your team that are due in the next two weeks. Both are easy to set up.
First, create your filters by clicking the “Filters” button in the toolbar. Add your filter conditions, and invoke your propensity to write logical statements:Click to add a filter from your workspace.
You should get something like this:Your logical cranium should come in handy here.
For many folks, this filter is actually enough. You can turn it on and off as you please and work out of here from this point forward. However, if you also want to save the project folder, release, users, grid columns, filters and more then you can save this as a tab. Click the + icon or right-click on your current tab to save what you see:Save your view as a tab. It makes things quite convenient.
Lastly, if your team uses Team Foundation Server, Github, or Tortoise SVN then you can do the following without logging into Axosoft.
- Tag an item with a source control commit
- Send comments to an Axosoft item
- Log a worklog against an item
As long as you jot down your Axosoft ID number, you should be able to log your work against your items without having to log into Axosoft. You will, however, need to log into Axosoft to change workflow steps–but that’s just a simple drop-down menu change, or a drag-and-drop into the appropriate workflow column. For instructions, check out our documentation page on Source Control.
Was this post helpful? Was it only mildly enlightening? Then comment below or send us a tweet on Twitter; feedback is a win win for everyone
The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management. I hope you like the information there.
If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.
A middle-of-the-night phone call is never a good thing – especially when the director of technology operations is on the other end. It was 2:00 a.m. in the summer of 2003 when I was abruptly awakened from my phone’s vibration.
My nightmare started as the director of technology operations reported that the system was down with no resolution in sight.
A company system outage is comparable to cutting off blood flow to the brain. When the system is down, there’s no cash and the business starts to die. No matter the size or stature of a company, technology leaders constantly carry the fear that even the smallest system outage could seriously damage their work. While this fear is hidden deep inside the psyche, it’s a reality that all tech leaders learn to live with.
My system outage was no different from eBay’s in the summer of 1999. The eBay auction site suffered from a series of system outages – the longest outage lasting 22 hours.
That outage cost eBay $5 million of transaction revenue. This $5 million may sound like a lot, but, in reality, it was nothing compared to the $4 billion drop in the company’s market value as the result of the outage.
WHAT ABOUT NOW?
Almost two decades later, and technology experts are still experiencing major complications in their systems.
In July 2015 alone, recent outages and system failures have affected the New York Stock Exchange, United Airlines, Department of State’s Visa system, Apple’s iStore, and – most notably – the Royal Bank of Scotland’s IT systems, which reported that a half-million financial transactions vanished from the system due to an unknown error.
They say “time heals all wounds,” but system outages may be the exception to this rule, as effects can be severe.
“For the Fortune 1000, the average total cost of unplanned application downtime per year is $1.25 billion to $2.5 billion,” says Stephen Elliot, IDC Analyst. “The average cost of a critical application failure per hour is $500,000 to $1 million.”
We are still not immune to these outages and we must take great care in avoiding these issues, or risk losing time, money and business.
WHAT IS HAPPENING?
Today’s systems are growing exponentially more complicated. Rising demand, volumes of aging data, patchwork of software, and network infrastructure each impact a system’s complexity and deployments. IDC estimates that the average amount of monthly deployments will double in two years.
To combat the case of system failures, technology leaders must adjust to an era of instant consumption – the “have to have it now” era. The world is no longer satisfied with singular massive updates to their systems every 12 or 6 months. Rather, we need to “deploy on demand,” where software can be updated several times per day with 100% resilience.
In other words, we need DevOps.
THE WAVE OF CHANGE IS HERE
Simply described, DevOps is the collaboration and communication between software developers and technology professionals in the IT value chain to deploy software to customers. Gene Kim, author of The Phoenix Project refers to DevOps as “the outcome of applying Lean Principles to the IT value stream.”
To achieve greatness, DevOps demands leadership vision and involvement. This requires sponsorship, so operational and cultural norms can change. It’s likely that your company will need to incorporate all of these changes to ensure long-term success.
DevOps is successful because it dramatically reduces a company’s operational risk by creating conditions that advance company culture, interactions, and tools.
Imagine a world where product, development, QA, infosec, and operations are orchestrating together to deliver business value at the fastest pace possible in an “IT value stream.” And fast execution isn’t the only benefit here – the process also has high predictability and low risk. This symphony of establishing a reliable flow across the organization – along with cultivating the right culture – is the foundation on which change can be made.
In May 2011, LinkedIn’s valuation doubled to $9 billion on its second day after IPO. With the stock soaring and a flood of new users flocking to the professional social networking site, LinkedIn was Wall Street’s golden child. Kevin Scott, LinkedIn’s top engineer didn’t feel as confident. Scott knew that the system and its engineers were being crushed by it’s own technology infrastructure inhibiting growth.
In a bold move, Scott launched Project InVersion, an initiative where all new feature development for LinkedIn stopped so that every engineer focused on rebuilding its core technology infrastructure. “You go public, have all the world looking at you, and then we tell management we’re not going to deliver anything new while all of engineering works on this project for the next two months,” Scott says. “It was a scary thing.” This work centered on LinkedIn’s ability to build out DevOps so that it could scale and accelerate while eliminating technical risks.
This resulted in extending the company’s deployment capabilities so that it can deploy changes at a moments notice at any time of day. Further, it helped support the growth of LinkedIn’s user base to over 364 million members and a market cap of $28 billion.
THE THREE LEADERSHIP MUST-HAVES
Gene Kim describes DevOps as a “philosophical movement.” And he’s right. As DevOps garners more attention, experts are deliberating its “best practices” and developing tools to support those practices.
To enable success, I have found there are 3 “musts” that leadership should have when launching a DevOps movement. These “musts” are based on the premise that DevOps requires disruptive leadership.
1. Executive Involvement
Leaders, including the CTO and the CEO, must work together to make DevOps a strategic priority. Just as soldiers, airplanes, satellites, and technology are strategic assets for the military, technology leaders need to utilize DevOps assets to achieve their goals. Leaders should engage with business counterparts when harnessing the strategic value of DevOps.
Successful DevOps transformations require executive participation and understanding. With the DevOps’ unification of the technology value stream, it becomes a unique strategic capability that enables faster innovation and faster time to market.
2. Organizational Design Focused on Agile Value Delivery
DevOps transformations are not simple. They are difficult and require creativity which leads to a journey that not all people in your company are prepared to take.
Value Driven Organizations
The best way to confront this challenge is to develop a healthy organization design. Separate organizational silos split by domains may be traditional; however, they are no longer effective. Many organizations, particularly those using Agile, are experiencing success by building cross-functional teams. Each team creates work in segments of time, or “sprints.” Each sprint results in the team delivering potentially shippable increments of work product. Moreover, place more emphasis on grouping team to swarm on delivering shared objectives. This structure will have a powerful effect on your company’s ability to collaborate and build business value.
This approach places more emphasis on teamwork. The teams design, build, and test as a team. And, throughout the development process, these teams actively coordinate with Technology Operations, InfoSec, and others to ensure that their work can be deployed.
Craftsmanship & Automation
Great DevOps companies require thoughtful and deliberate decisions to encourage great engineering craftsmanship. This craftsmanship ensures software is built with practices that encourage high quality product. The practices we follow should focus on receiving fast feedback on whether or not the code really works.
Today, practices like Test Driven Development (TDD) are used to create lines of tests before the code is written. By writing the code to after the tests are created, developers create a collection of code that, by definition, is already tested before it’s finished, thus reducing errors in increasing quality.
Automation is another key element to the product development flow. Once automated, a developer can automatically test the code with a simple click. The system can test the changes across thousands of developers’ new code in a fraction of time compared to manual tests.
3. Synchronized Product Planning and DevOps Planning
Several successful DevOps groups are also accelerating their delivery capabilities with support teams. Technology operations, infosec, architecture, and risk/compliance teams are often involved in product planning.
This results in a higher degree of coordination in the product development cycle. Aspects of security, scalability, reliability, are baked into the solution from the earliest stages of planning. Moreover, by tying together areas of release management practices at the beginning, the organization’s ability to coordinate product delivery matures faster.
DevOps may seem like a lot of work, but technology leaders should consider it a smart business investment. Companies unwilling or unable to adapt will be left behind and trapped under the weight of their own antiquated practices. Those slow to react will not be able to compete due to limitations of deployment speed and resiliency. However, it’s the companies employing DevOps that will outmaneuver and outpace their competition, leaving others in the dust.
Stacey Louie is the CEO of Bratton & Company, a leading Agile Transformation consultancy based in the Silicon Valley. As an Enterprise Agile Coach, he was instrumental in PayPal’s 400 team global agile transformation as well as supporting other Fortune 500 companies including Cisco, Hewlett Packard, and eBay. He also held the position of division CTO/CIO of public companies including Verisk Analytics and Stewart Information Systems.
A wish list of books I'd like to read...
Passionate Performance by Lee J. Colan
This quick read cuts through the clutter to offer practical strategies to engage the minds and heart of your employeees. Learn why this is such a powerful advantage for your organization. Read it and conquer your competition!
Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal
A NEW APPROACH FOR A NEW WORLDMcChrystal and his colleagues discarded a century of conventional wisdom and remade the Task Force, in the midst of a grueling war, into something new: a network that combined extremely transparent communication with decentralized decision-making authority. The walls between silos were torn down. Leaders looked at the best practices of the smallest units and found ways to extend them to thousands of people on three continents, using technology to establish a oneness that would have been impossible even a decade earlier. The Task Force became a “team of teams”—faster, flatter, more flexible—and beat back Al Qaeda.