As many as 94% of organizations are practicing some form of agile according to 9th annual State of Agile survey™, yet I have first-hand experience seeing countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach.
So how can you tell if your organization is doing agile right?
The Top 1% of the Top 1%
There is a vast difference between the way Olympic sprinter and world record holder Usain Bolt approaches his goals and how an everyday person trying to lose weight by running approaches their goals. Usain Bolt is the elite of the elite, in the top 1% of the top 1%. His approach to training is irrelevant and unrealistic for an everyday person trying to lose weight.
Your organization isn’t like an everyday person trying to lose weight. Whether you’re a startup or a Fortune 50 company, you’re striving to be or maintain being in the top 1% of the top 1%. You can’t afford to approach anything like an everyday person. You must have the same fierce focus as Usain Bolt.
So, let’s go back to the question. What kind of agile are you, or better stated, what kind of agile is your organization? Is your organization truly agile or just superficially so?
I’ve put together some comparisons of the approaches of Usain Bolt, everyday people and agile organizations.
Usain Bolt and his team of coaches, managers and agents have a single vision—for Usain Bolt to be one of the greatest athletes of all time. To do this he must win medals and break world records. If he is breaking world records, then everything else falls into place. Usain Bolt isn’t focused on beating the competition; he is focused on continually improving in order to break his own world records.
“If I want to be among the greats of [Muhammad] Ali and Pele and all these guys, I have to continue dominating until I retire” – Bolt
Most everyday people trying to lose weight don’t have a true vision. Yes, they wish they could lose some weight, but most everyday people don’t have the fierce focus on meeting their running goals. Nor, necessarily, should they. Most of us everyday Joes have other things to focus on like family, work and paying the bills. While our health is utterly important, it gets deprioritized because our commitment is superficial and we skip runs and sneak snacks.
Is your organization truly agile or just superficially so?
Saying you’re agile isn’t enough to be truly agile. Having teams that do stand ups isn’t enough to be truly agile. Having a Kanban board isn’t enough to be truly agile. True agile is about organizational agility and organizational agility starts with a vision: a vision from the top that is burned into the hearts and minds of the entire organization.
Your agile transformation must be aligned to your strategic goals. Both must support a single vision that pumps through the veins of your organization. If you don’t have that, then you’re just a guy running through the motions so that you feel a little less guilty the next time you have a bag of chips.
The Litmus Test
If you’re ready to face the truth and find out whether your organization is truly agile or just superficially so, try exploring the following six questions.
- What is your organization’s vision?
- What are your organization’s strategic goals?
- What are your organization’s agile vision and goals?
- On a scale of 1 to 10, how aligned are the organization’s vision and strategic goals with your agile vision and goals?
- On a scale of 1 to 10, how well does the organization understand this vision and these goals? This includes executives, program managers, project managers, dev managers and dev team members.
- On a scale of 1 to 10, how strong is the executive support of the agile vision and goals?
While 94% of organizations are practicing some form of agile, according to 9th annual State of Agile survey, I have witnessed first-hand countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach. Don’t get caught in the trap of thinking you’re agile just because you’re doing stand ups or have a Kanban board. I hope this has inspired you to take a few minutes to really reflect on whether your organization is truly agile or just superficially so.
What are some other ways to tell whether your organization is truly agile or just superficially so?
State of Agile is a trademark of VersionOne Inc.
Agile at scale essentially boils down to this: Agile teams working with the business to deliver value to market fast and predictably. Though the principles of Agile development — cadence, collaboration, synchronization, etc. — remain the same, planning and delivery are different at scale.
Coordinating complex development across teams requires a different approach. It means putting business value first and coordinating that work across multiple teams. Rather than try to dissect the work in process team by team, delivery leaders need an at-a-glance view of the overall progress of the release and the features planned — plus the ability to identify problems quickly so they know what conversations to have and what roadblocks to clear. Rally’s powerful new Release Tracking page provides just this — a bird’s eye view of where your release is and the problems you need to manage.How It Works:
Scoped to a specified release, the Release Tracking page shows all the features planned and the teams working on them.
Select a Feature to see which teams are working on it and its development progress.
Rally’s %done indicator highlights the overall progress of a feature and shows each team’s progress in any iteration. Color-coded progress indicators signify whether a team or feature is on track for delivery by the planned end date. Red means potential trouble, and an area to explore further.
Dependencies across teams often derail progress. On the Release Tracking page, dependency lines quickly indicate when teams are misaligned on dependent work.
The page also includes a warning indicator to communicate several potential issues with a feature that may delay its completion — including blocks and dependencies.
With Rally’s Release Tracking page, it’s easy to keep tabs on overall progress and identify problem areas. You’ll see when teams are on track, so you don’t bother them with questions about their progress. And when issues do arise, you’ll know the right conversations to have at the right time to resolve dependencies, mitigate risks, and keep the delivery group humming.Get Started Now
As of June 17, all Rally Portfolio Manager customers using our enterprise SaaS platform have access to the new Release Tracking Page in open beta. Use it during your next Big Room Planning event to see how your plan is coming together, in realtime, in a single view. And keep using it to help steer your release on time, as planned.
To learn more about the Release Tracking page in the Rally platform, watch the demo video below, reach out to your Rally Solution Architect, or take a Rally product tour.
We are thrilled to announce the availability of Rally’s capacity planning capability — built for the program and portfolio level of enterprise scale Agile. With the new Capacity Planning page in the Rally platform, strategic planners can rapidly translate their business initiatives into realistic and adaptable action plans, without relying on disconnected, manually updated spreadsheets.
The new Portfolio > Capacity Planning page provides a staging environment for portfolio, product, and engineering leaders to collaborate ahead of release planning — without impacting the productivity of Agile teams that are busy delivering on the current quarter’s commitments.
Planners can play what-if scenarios to optimize the value of their near-term delivery plans, as well as create longer-term plans to inform hiring decisions. By creating multiple scenarios, business and technology leaders can review the realistic options of turning business initiatives into action before deciding on the final game plan.Less is More
It’s hard for businesses to accept the paradox that the less you do, the more you actually get done. Working on 10 different things at once is the recipe for delivering none of them.
The magic of the new Capacity Planning page is its sheer simplicity in visually identifying the right teams and the right scope — and right amount of scope — to bring into a quarterly release planning event. The page is instrumental in helping organizations build the predictability their business expects, and that predictability only comes when the right work and the right amount of work flows through coordinated, stable teams that have learned to work together to deliver quality, fast.
The Portfolio > Capacity Planning page
The new page is driven by four inputs:
Planning timebox: To adapt quickly to market and business changes, planners should have defined their continuous planning cadence. Using the planning timebox, they can select the time span for their capacity plans — from a single quarter or release for near-term planning, to multiple releases.
Prioritized feature backlog: Product managers should have validated a clear and ranked list of coarsely described features deemed most valuable to the business, tolerating incomplete data by delaying more detailed feature descriptions until what fits in a release is identified with the capacity planning cut line.
Rough estimates: Estimation teams — typically comprising team leads, architects, and other experts — should have provided roughly right estimates, tolerating incomplete data until release planning when those doing the work can provide more-refined estimates without impacting team productivity.
Teams: Engineering directors should have identified the teams involved in the capacity plan, following the team as the resource unit recommendation over individual roles and skill sets that provide a false sense of precision and accuracy.
The Rally Capacity Planning page delivers immediate benefits:
Limit WiP: Being able to see when capacity is reached ensures planners only schedule the work that matters most, and delivery teams can focus on delivering the plan faster.
Delivery predictability: By focusing on fewer features that matter most (as opposed to constantly context switching), teams can build delivery plans with predictable outcomes.
No time wasted detailing features for which teams don’t have capacity.
A solid, realistic plan to bring into release planning that optimizes the business investment in that event.
The Capacity Planning page has even more benefits that become obvious after you start using it. Our early adopters found the page instrumental in removing the emotions from deciding what Agile teams should work on by matching demand and supply in a visual, data-driven, quantitative way.
Quantitatively matching actual capacity to business demand with a dynamic cut line
When business leaders were too busy to collaborate in release planning, early adopters used the new page to present different scenarios instead of saying “We can’t do it all.” Executives were more engaged and appreciated the opportunity to review alternate, realistic options.
Last but not least, there’s an acute shortage of skilled development professionals. Businesses seeking to retain existing talent and attract new talent need to create an inviting development environment that respectfully balances employees’ time and capacity.
The capacity planning capability is the result of a year-long engagement with customers to understand how to best support Agile organizations in effectively leveraging the power of stable, cross-functional teams to meet growing and changing business demand. We’d like to extend a heartfelt thank you to the customers who helped us validate this functionality over the past year.
On June 17, Rally® Unlimited Edition customers will have access to the new Capacity Planning page and all the benefits that come with it — just contact your Rally Solution Architect to get the capability enabled in your subscription.
For more information about capacity planning for the fast-paced world, download the white paper.
As more of my clients transition to agile, many of them have a fascinating question:
How do I assess who is doing what on my team?
When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation.
When I ask why they want to reward individuals instead of the team, they say, “I am sure some people do more work than others. I want to reward them, and not the other people.”
Interesting idea. And, wrong for agile teams. Also wrong for any innovation or learning that you want to happen as a team (regardless of whether you are agile or not).
Agile is a team-based approach to work. Why would you want to reward some people more than others? If the team is not sure that they are working well together, they need to learn to provide each other feedback. If the team doesn’t know how to manage team membership, a manager can facilitate that membership discussion and problem-solving. Then, the managers can transition team membership issues to the team, with manager as backup/facilitator.
What I see is that the managers want to control team membership. Instead, why not let the team control its membership?
I often see that the managers want to control feedback: who provides it and who receives it. Instead, why not train everyone in how to provide and receive feedback?
When managers want to reward some people more than others, they imply that some people are less capable than others—something agile is supposed to fix with teamwork. Or, they wonder if some people are wasting time.
If managers trust their teams, managers don’t need to worry about accountability. They don’t have to worry about people “wasting time.” Agile creates transparency, which helps people to learn to trust each other and know when they are working on relevant work or not. If you encourage the team to add pairing or swarming (or both), you have the recipe for whole-team work and team momentum.
I don’t know anyone who goes to work thinking, “How can I waste my time today?” Do you? (If you do, why is that person on your team?)
I know plenty of people who do waste their time, because of technical debt, or experts creating bottlenecks, or team members who don’t want to work as part of a team. I bet you know many of these people, too.
But I don’t know anyone who wants to go to work to waste time and collect a paycheck without doing anything. Sure, there might be some people like that. I don’t know any.
In an agile team, the team members know who works hard and who doesn’t. A manager could trust the team to handle their compensation.
And, that would mean the manager has to relinquish control of much of what managers have done recently.
- The manager would have to provide feedback and meta-feedback to people who want to learn how to provide and receive feedback.
- The manager might provide coaching as to how to work in a team effectively. (This can be tough if a manager has never been part of a team that worked well.)
- The manager would allow the team to control their compensation.
There’s more, and I’ll stop there.
What would managers do? They would stop interfering with the team’s progress. The manager might read “If Managers Don’t Give Performance Reviews, What Happens?”
Managers control much less in agile. Managers enable more. They have to trust the teams. This is a culture change.
If you can’t trust your agile team or its team members, there is something wrong. You can investigate and either fix (manage the project portfolio) or ask the team to fix it (maybe with retrospectives as a first step). If you need to know who is accountable for what, you are asking the wrong question. The answer might be you.
If you are managing an agile team and you want to know about individual work or accountability, ask yourself what you really need. Ask yourself if there is another way to obtain the results you want. Maybe you won’t waste quite as much time.
In general, the product owner's job is to specify what to build, not how to build it. But, there may be times when it is appropriate for a product owner to specify some architectural decisions.
For example, years ago when Sun was seeking to promote the Java language, they offered money to companies who used Java to develop certain applications. A couple of product owners I worked with back then mandated that their teams use Java.
In some cases, these were applications with marginal business cases that would not have been justified without funding from Sun, so those mandates made sense. The developers didn’t object because they wanted to experiment with the hot, new technology of the time.
A product owner mandating a technical decision should not happen often and product owners should exercise great care in doing it. And product owners who do so had better be right when they dictate a technical decision.
In most of the cases when they dictated Java, they really weren’t right—Java in its early days really wasn’t up to some of the challenges of some of those applications.
As another example, consider an embedded device. The product owner has decided the product will be economically viable if produced on a particular piece of hardware, but not on a more expensive piece of hardware.
The product owner may tell the team that they are restricted to using the lesser hardware. Sure, the team would probably prefer the more expensive hardware, but the product would not be economically viable then.
So, product owners can dictate architectural decisions. But they should do so sparingly, wisely and ideally, in consultation with the team.
“Coaching is the universal language of change and learning.” – CNN
In our previous post, we’ve provided you with some hints on how to build a good agile team that will work like a well-oiled machine. We agreed that building a team isn’t very easy, but it’s still feasible and necessary in order to achieve extraordinary results.
As a matter of fact, pulling people together and maintaining the team in a good spirit can be even harder. This is the time when agile coaching can give us a helping hand.
Anthony Robins (famous life coach) coined a term CANI – which is an acronym for Constant And Neverending Improvement. The key word here is an improvement. Therefore, we cannot say that agile is yet another process – an agile approach is a means of improving everything – c o n s t a n t l y.
Here we have a space for agile coach that can help the team to understand why, what they’re doing really matters, and why the agile way matters.
But what is an Agile Coaching, anyhow?
Agile coaching competency framework
Agile coach should aim to “grow a productive Agile team that thinks for itself rather than relying on you to lay down the agile law”.*
As we can see it’s not about simply showing the right path but rather helping the team to find their own way within an agile environment.
We can boil down the agile coaching to five elements:
Mentoring – a coach is a helping hand that can provide the team with necessary advice when it’s needed. It’s quite critical for a coach to have a wide range of knowledge and experience not only in the scrum methodology. Moreover, agile coach needs to lead by example, simply walk the walk, so to speak. So if a coach wants to teach about agile principles, he needs to follow the agile rules himself during daily work.
Training – agile coach needs to pass all necessary knowledge and enforce it into practice. It’s not a rocket science, every team is different, made up of various people with different experiences and abilities in acquiring knowledge. That’s why a coach needs to remember to adjust the form of information flow to a particular team.
Management – however not managing people but managing the process itself. As we have agreed – agile is a process of constant improvement.
Coaching – it’s a partnership process, during which a coach supports the client (can be a group or a team) in making the best use of his potential in order to achieve particular goals. How does it get done? By asking proper questions, by understanding the team’s flow and all the habits that come with daily work. A coach should help his client transform to the point where he wants to be.
Assistance – coach needs to facilitate with solving all the issues that will occur somewhere along the line with all his experience and knowledge.
Well, considering the above fact it seems that being agile coach is not a piece of cake. But who said it’s going to be easy anyway? :)
It appears that the hardest part in becoming a good, agile coach is developing all of the earlier mentioned competencies. Agile coach needs to have a wide range of knowledge as well as skills to perform all those roles.
Agile coach should aim to “grow a productive Agile team that thinks for itself rather than relying…
Click To Tweet
So what skills are important to be developed for agile coaches? As Rachel Davies wrote:
- Working with people: listening, giving feedback, asking questions, building trust and rapport
- Facilitating change: enlisting support, reaching agreement, spreading success, learning from failure
- Systems thinking: seeing the bigger picture, identifying levers for change, communicating danger signals
Benefits from agile coaching
Implementing scrum in an organization is often perceived as a remedy for all the problems that a company suffers from. But (as you may have experienced in your companies) implementing scrum isn’t a very easy task and can entail a lot of other problems.
That’s why agile coach is a must!
So here we have some of the benefits that a company can get from implementing an agile coaching:
- An outside view – coaches bring a new perspective to the organization, team and individuals and they remove intrinsic bias and interpersonal issues.
- New opportunity for improvement – a good coach provides learning and training for the employees and develops their skills
- Facing the problems – agile coaching creates an environment that allows teams to face the difficulties and work on a proper solution instead of sweeping problem under the table.
- Saving time and money – coaches bring both the tried and the new practices and processes to a team and organization, reducing the degree of trial and error commonly found in homegrown experimentations.
One size doesn’t fit all…
Just remember that agile coaching is not a holy grail for all the problems that you might encounter with your team.
“Every technique is working and is not working at the same time”
which means that a technique or a solution that was used for one team can work and, on the other hand, can be useless for another team. It’s all about the context and about people.
Picture (with small changes) courtesy of Brain vector designed by Freepik
At Ivar Jacobson International (IJI) we have been involved in many agile adoptions ranging in size from single teams to entire IT development organizations. The single biggest problem we see is organizations not understanding why they are changing the way they work – they don’t visualize the goal, set any targets, measure the improvements, nor demonstrate the benefits generated.
This isn’t a problem where an empowered team is looking to improve their own way-of-working. However, it is often a showstopper when attempting a broader adoption, such as an organizational transformation or where the team is not yet empowered.
The key here is to establish a set of actionable measures to drive the change and inspire the teams. These should explicitly support the principles and values being promoted and challenge the teams to improve.
In this article we will look at one way to establish a measurement dashboard to support your agile transformation.
What Should You Measure?
To gather empirical evidence of the effect of the transformation you need to have both:
- Measures of the improvement – measures that quantify how well the transformation is going, the amount of cultural change and benefits being generated. For the teams to be truly empowered these measures should be kept as process and practice independent as possible.
- Measures of the mechanisms that produced the improvement – measures that quantify what is being used where, demonstrate the uplift in capability across the agile teams, and show whether the transformation is on track to achieve self-sufficiency
These measures will complement and, in many cases, reuse the measures that are being used by the teams to drive and control their work.
In this article we will focus on how to measure the improvements. The sad thing is that there is no standard set of improvement measures that can be promoted or prescribed as suitable for all agile transformations. Each agile transformation is different; with different goals to achieve and problems to address. What is needed is a set of measures focused on the improvements that need to be made. This set of measures will need to be inspected and adapted to ensure that it continues to be relevant as the transformation progresses and the initial improvements are built on to generate more and more business benefit.
Measuring the Improvement: Building an Improvement Dashboard
Our preferred approach to establishing an improvement dashboard is to use our Better, Faster, Cheaper, Happier framework. This is summarized in Figure 1 below.
This is a simple framework that helps organizations produce a balanced set of improvement measures that are aspirational rather than operational. It is important to achieve a balance between the measures, so that you don’t increase delivery speed whilst sacrificing employee or customer satisfaction, or improve quality whilst lowering productivity.
This proven framework helps organizations to identify and implement practical measures that:
- Focus on the real business drivers, goals and benefits
- Measure the things that really matter – the effects not the causes
- Show whether things are really improving – eliminating seasonal fluctuations by looking at performance over a year, not a week or month
- Consider how people feel – gathering both qualitative and quantitative data
- Are simple and easy to understand – not complex derived measures and indexes
- Don’t depend on using particular processes and practices – allowing the old and new worlds to be compared
- Have relevance to the business – clearly showing where the business would like to see improvements
- Have targets and obvious trends – the on-going trends are more important than point measures
The result will be a set of measures and targets that everyone can understand and support.
Some Illustrative Measures
There are lots of measures that could be relevant to your transformation. For illustrative purposes Figure 2 shows a compilation of some of the measures that we have seen to be popular within organizations embarking on large-scale agile transformations. For example, when starting out nearly everyone targets on-time delivery before focusing on cycle times – as a wise man once told me less late is still late.
A couple of things to note about this dashboard are:
- This is an illustrative dashboard and has never been used in this form by any specific organization. All the customers have used some of these measures, but they have also all had their own specific measures to address their specific problems.
- This probably lists too many measures for use at any one time. Most adopters start with eight or so measures, which is more than adequate to cover the four quadrants. At IJI we have built up a library of more than 30 candidate measures that support common organizational goals. The important thing is to understand the goals and the underlying concerns rather than to just go shopping for measures.
The measures shown in Figure 2 are:
- On-Time Delivery – Percentage of releases that are released on-time
- Escaped Defects – Mass of defects that escaped from 1) development teams to acceptance test and 2) from acceptance test to live in the last year
- Meets Business Needs – Survey of whether the customers think the software delivered met their business needs
- Level of Priority 1 Incidents – Number of priority 1 incidents reported in the live environments in the last year
- Time to Production – Number of weeks it takes for a project to get a release into production once the project is started banded by overall project cost
- Decision Making – The time it takes to commit to progressing a project or producing a release from decision to evaluate the request
- Timeliness of Delivery – Survey of whether the customers think that the software was delivered in a timely fashion suitable for their business
- Improved Value for Money – Survey of whether the customers think that the software represents good value for the money spent
- Overheads – The cost of non-productive work done by the development teams (such as fixing escaped defects, support, administration etc.)
- Stabilisation and After Care – The cost of stabilising and supporting releases in the warranty period after they initially go live
- Business Satisfaction (organisational level only) – Survey of whether IT’s business partners are happy with the service provided by IT
- Team Satisfaction – Survey of whether the teams developing the software are satisfied with the way that they work
- Customer Satisfaction – Survey of whether the business representatives and users directly involved in the teams’ work are satisfied with the way the teams work
It is important that all the teams, projects and programs within the scope of the transformation, regardless of their level of agility or buy-in, can use the dashboard. For example, KPN in Netherlands was one of the first organizations to use the framework. They applied it to more than 14 programs and 400 projects within their IT Innovation organization. In the spirit of autonomy and empowerment the programs were allowed to opt out of the transformation if they were confident they could meet the targets. Unsurprisingly the teams that decided to stay with a waterfall way of working showed little or no improvement across the board falling well short of the average performance in all cases. For more on the KPN measurement story see http://www.ivarjacobson.com/resources/resources/case_studies/
The dashboard is created through a series of short workshops where the objective is to understand the most important areas to improve, and to identify practical, intuitive measures to evidence the improvements. The people involved should include leaders, executives, customer representatives, senior managers plus other key stakeholders with a specific interest in the improvement goals and results.
The workshop helps participants to understand the business drivers, goals and needs, and set some meaningful improvement targets. It starts by simply brainstorming what the words better, faster, cheaper and happier mean to the participants focusing the conversation onto the goals of the transformation, and proceeds through various rounds of discussion, consolidation and voting to identify key areas for improvement. This helps to quickly establish what measureable benefits are expected from the transformation and makes sure that they are aligned to the business goals.
The end result is an overall dashboard containing a set of intuitive measures that support the organizational goals and present the overall targets for the next stage of the transformation. This enables everyone to see the targets, the current status, and the improvements taking effect. Typically the measures are captured on a monthly basis providing an instant feedback mechanism on the effectiveness of the approach and whether or not the desired improvements are materializing.
A truly agile organization is a learning organization that is continually refining and improving all its practices. It is an organization that is focused on continuous improvement and delighting its customers.
To reach this promised land you need a laser-like focus on results, whilst not forgetting why you are implementing an agile approach. Too many agile transformations stall when they are unable to demonstrate that the new way of working is any better than the old way. The mistake they make is to think agility is an end in itself rather than an enabler for better business performance. Quantify the results you are looking for and make sure you measure the effect of the transformation.
It’s astounding how many agile transformations fail to track the benefits they are generating, and in many cases seem to leave the organization no better off than they were before. The people involved, particularly the sponsors and other executives, can also be very impatient. Creating an agile organization is not something that happens overnight. Agility is no silver bullet and not every agile team, or project, will be successful. Patience is needed to see the transformation through and reap the full benefits of agility. Measurement is needed to make the benefits visible.
In our experience the biggest benefits are achieved in the second year as agility becomes business as usual and the effects of agile working ripple through the value chain. Sadly if you don’t demonstrate how you are going to measure the improvements and make them relevant to the business you often don’t get a second year.
I was teaching a private class a few weeks ago and a student in the class mentioned that his company had “already failed at Agile three different times.”
The way the statement was phrased really struck me. It made me very aware of my own opinions about Agile adoption and taught me a little about how this particular student, and possibly the organization, felt about adopting Agile.
What struck me was how easily the previous efforts were declared failures. If they truly had failed, there was no way I’d have been in the room teaching a private CSM class. It is possible that the company did not fully reach the perfect state of Agile nirvana and was not able to enjoy the bliss of a friction-less work environment populated with completely realized, high-performing teams of enlightened humans who delivered shippable product every sprint in a self-organized, cross-functional manner. Instead, they learned how not to transform the company… which is not a bad thing, because every misstep gets them one step closer to the solution that will open the lock (or at least a part of it.)I have not failed. I’ve just found 10,000 ways that won’t work.
Let’s say you have a guy who loves to sit on the couch binge watching old TV shows while jamming Ho Hos and Mountain Dew down his throat all day. He hears about people running marathons and decides this is for him. He goes to the mall… buys some expensive running shoes, a sweat suit, special moisture wicking socks… the whole bit. Then he stops by the “24 Hour Buffness” gym (which, shockingly is having a new membership special) and he signs up for a yearly membership. Then he goes home, puts on his new running shoes with the special moisture wicking socks, his new track suit, grabs his 24 Hour Buffness Membership Card, plops himself down on the couch, cracks open a fresh can of Mountain Dew and a brand new Ho Ho. Then he fires up Netflix and puts on The Rockford Files, Season 5, Episode 4… The one where Tom Selleck guest stars as horribly annoying Lance White. Two days and 12 episodes later, our man realizes he’s not been to the gym, is not in shape, but seems to have consumed his weight in Ho Ho’s. If you ask him about it, he’ll explain how his situation is different, he can’t just start exercising like everyone else, The Rockford Files is not going to watch itself and let’s face it, that Lance White episode is a critical moment in Detective TV History. No Lance White, no Magnum. No Magnum, no Simon and Simon/Magnum mash-up episode… and then where would we be?
The real question is, has the “get in shape and run a marathon” project failed at this point? Or has he just not figured out the right way to get him motivated to change his lifestyle yet?
Now… imagine you had a building with 1,000 people just like him. Has the entire building failed? No… we just haven’t figured out the right way to make it work yet.
Change of any kind is difficult. Just because it doesn’t completely stick on the first try doesn’t mean it has failed or it didn’t work. It just means you did not figure out how to make it work YET.
And if you happen to work in an organization that has coaching and/or training for Agile, take that as a very positive sign. If the organization is willing to commit at that level, it’s a very good start. There are many places out there that are still convinced they don’t need help figuring this out.
Whether you want to call it transformation, adoption, “Project Nimble”, or whatever… the journey from a traditional approach to Agile is a long one. Transformation has to occur at multiple levels and it requires deep change to work practices and work culture. It may not happen all at once, it may be too tall of an order to just completely go Agile all at once. You may need to do it in stages (Basecamps). Your organization, like many others, may go through a number of attempts before things begin to stick.
If you know the old way doesn’t work, you have to make a choice. This choice takes place at an individual as well as an organizational level. Do you want to keep working in the old way, with annoying, but familiar pain? Or do you want to take a chance at trying something different that just might offer you a path to a better world of work? If you want the latter, you need to be willing to work for it, be patient and commit to keeping at it until you reach your goals. And, like any good sales person will tell you, No just means you haven’t figured out the right way to ask the question yet. When you do find it, they’ll say, “Yes”.
The post Agile Transformation … Learning What Doesn’t Work Is The Key To Success appeared first on LeadingAgile.
A modern leader is someone who succeeds through the achievements of her employees. A great leader is someone that sets the direction and supports the environment in which the employees can act and evolve. A great leader is someone that sets the boundaries for the team, but leaves space and freedom for the employees to take responsibility and improve.
To grow into a modern leader you will likely need to unlearn what you were taught at business school and by traditional managers who mentored you. Read more from Peter Hundermark’s latest blog post on ‘Growing Leaders‘.
Leading Self-Organising Teams course Masterclass for Agile leaders and professionals
- Understand the principles of Agile Leadership
- Learn and apply state-of-the-art leadership tools
- Enrich your skill set through practical role plays
- Cope with tricky situations and identify blind spots
Only a few spots left, so be sure to book your place and get equipped to face the complex leadership challenges of the 21st century.
When: 07-08 July 2015
Where: FNB Conference & Learning Center, Sandton
Certified Scrum Master (JHB)
23-24 June 2015
Certified Scrum Product Owner (CPT)
29-30 June 2015
Leading Self-Organising Teams (JHB)
07-08 July 2015 (Only 6 spots left!)
Visual Facilitation Foundation Workshops
27 July 2015 (CPT)
30 July 2015 (JHB)
Visual Facilitation Advanced Workshops
28 July 2015 (CPT)
31 July 2015 (JHB)
The post News update 2015/06 – Creative Visualisation Workshops appeared first on ScrumSense.
My daughter’s FFL Lego Club is over for the year, but I wanted to two helpful debugging things I learned along the way, that were especially helpful for newer kids.
This was the first year for a group of 5th and 6th graders and I noticed many of them ended up with some long procedural blocks of code to navigate the robot through obstacles across the board and back to the base. A really common problem was they’d make some progress, and then come back to the table only to discover the robot didn’t do what they expected after a “small change.”
The first fix for this was actually saving a copy off before making significant changes, just giving it a new name. The Lego LabVIEW environment didn’t make this easy as you have to cut and paste the blocks by hand into a new program, but it saves a lot of time with the kid’s longer programs. I’ve used Git for the same effect, but source control isn’t the focus here.
A second quick win was testing with the robot connected. Our boys and girls were very set on the program, download, run to the table loop, but I eventually had a few of them persuaded to test with the robot just connected via USB. The best part of this is you can select a single block and then run just that block with the robot. We used this several times to troubleshoot issues with arms that swung back too far and got stuck on lego pieces, which halts further execution and doesn’t give much feedback on what’s wrong.
Finally was the one I had the most fun with. Many kids’ programs had dozens of blocks connected. Often they would forget where they added tweaks to turn left, spin, or adjust the shooting arm. As a lover of sound effects I suggested adding sound effects before and after they added their tweaks so they’d know several things:
- Did my changes actually get loaded on the robot?
- Did my changes improved the program?
- Exactly where to tweak the program again if it just needed another adjustment.
The sounds were fun on their own and they can easily be deleted when the program is ready to go.
There are plenty of people who would tell you that an Agile transformation should be conducted slowly and gradually. Not Physicians Mutual.Taking Center Stage at RallyON
This week at RallyON!™ 2015, our friends at Physicians Mutual will be up on the main stage, talking about their unique and successful approach to an Agile transformation. We’ll share that video later so you can watch for yourself! Meanwhile, here’s a sneak peek into the story.The Big Bang Approach
In just few months, Physicians Mutual’s Enterprise Technology Group (ETG) launched 14 teams simultaneously and started running coordinated midrange planning sessions to deliver business value faster. No pilot. No staged rollout. Just a deliberate, well-planned effort to adopt enterprise scale Agile and the determination to see it through.
We refer fondly to Physicians Mutual’s rollout as the big bang approach. And it worked. The group went from 4 to 6 major releases annually, plus minor releases at the end of each 3-week iteration. As a result, ETG delivers hundreds of roadmap items over the course of a year, and they’re doing it with higher quality.How Did They Do It?
There are many factors in Physicians Mutual’s success with Agile, not the least of which is the expertise and tenacity of the people. But there’s another secret ingredient to any successful enterprise scale Agile transformation that we call big room planning.
Big room planning gets everyone in the same room to plan the work for a release. It’s an opportunity to confront key risks and dependencies. It’s a chance to make unforeseen connections. And it is the place to link strategy to execution.
Physicians Mutual has been doing this successfully since launching its Agile transformation, and it’s keeping ETG moving in the same direction.Find Out More
This is a great story — one that we love to tell at Rally. We look forward to hearing the long version of the story straight from the team that made it all happen at Physicians Mutual.
Axosoft first partnered with Girls In Tech, an organization focused on empowerment, engagement, and education of women in technology, earlier this year for their Catalyst Conference. We have since strengthened our relationship with this organization that aligns so closely with our company’s values and the goals of our #ItWasNeverADress campaign. In fact, Axosoft CEO, Lawdan Shojaee, is so committed to this partnership, she is one of ten new outstanding business leaders who were just appointed to the Girls in Tech Board of Directors. All ten members are CEO’s or Senior Executives in their fields.
The new Girls in Tech board members are:
- Lawdan Shojaee, CEO, Axosoft
- Monique Morrow, CTO, Evangelist New Frontiers Development and Engineering at Cisco
- Sandy Carter, General Manager, IBM Ecosystems and Social Business Evangelism
- Fran Maier, Board Director of G.E. Capital Bank, Founder of TRUSTe, and Co-Founder of Match.com
- Darrell Mockus, CTO, CPP Innovation Labs
- Bev Crair, VP and General Manager, Storage Group, Intel
- Elizabeth Davidson, Co-Founder, Diamius Multinational
- Denise Terry, CEO and Co-Founder, EmbraceHer Health
- Donna Boyer Chief Product Officer, Blurb
- Lori McLeese, VP of Human Resources, Automattic
These heavy-hitters showcase a lengthy list of skills that are beyond impressive! With their love for mentorship, unmatched experience in the STEAM space, entrepreneurial skills, major international relations, and most importantly, amazing life experiences to share, this group has a combined leadership resume that will be a huge asset to the Girls in Tech global organization.
Together, Girls in Tech and Axosoft are helping pioneer change during a challenging and exciting time, as discrimination in education and equality in the workplace continues to be an issue, and the demand for technological innovation continues to rise.
“I can’t wait to put my energy and my efforts towards GIT, and together, help shift the perceptions of females in the industry. Together, we can help change the landscape for our next generation,” says Lawdan Shojaee, CEO of Axosoft.
We are all hands on deck when it comes to supporting Girls in Tech. We are looking forward to four main programs with the organization this year:
- Lady Pitch Night Competition
- Catalyst Conference
- GIT Bootcamps
- GIT Hackathons
Lots of work ahead but nothing this group can’t handle!
Girls in Tech is the largest global organization in the sector, creating awareness of the need to recognize women’s contributions to technology and promoting women working in the workforce. With over 47 active chapters and approximately 22,000 members, the organization provides Global Classroom courses, coding and design boot camps, confidence-building and product development, entrepreneurial and leadership programming, business pitch competitions, hackathons, networking events, conferences, and sponsors young girls in high school and middle school to participate in STEM workshops.
As Roy McAvoy (played by Kevin Costner) said in the movie Tin Cup, “Tempo is everything; perfection is unobtainable…” McAvoy was describing a golf swing with these words, and anyone who has played a round, been to a driving range, or even observed the professionals on a televised tournament can attest, the perfect swing is not out there. Yes, there are many swings that are close, but none are perfect and even if you catch lightening in a bottle for one swing you can’t recreate that swing consistently. At least this is my experience. I can’t get that ball to go where I want it to every time. I don’t hit each green. And definitely don’t sink every putt. But enough with golf.
My point for bringing up the golf swing was to point out it’s similarities to an organizational transformation. Whether you are trying to shift to a paperless office, become a more collaborative organization, or transform your organization into an entirely agile enterprise, I can tell you now, the perfect picture state you have in your head about what your organization should look like after this endeavor, is not going to be what your organization looks like. Also, it will probably take longer than you are hoping for.Perfection is Unobtainable
You are not going to be perfect, no one is. I use the goal of the perfect end-state as a gauge to identify which areas we need to focus our efforts to improve upon in order to move us towards the perfect picture. To act as though we are failing because we are not perfect is not a sustainable solution. Strive for perfection, but know that you are not going to obtain it, and you can rest assured knowing that the drive towards perfection, not being perfect, is what is going to set you apart from your competitors.Tempo is Everything
I have come to realize that we can only change at a certain pace. I have not been a part of a team that was able to successfully take on everything they needed to change and complete it in a day. I have observed many who have tried but they only ended up making things worse for themselves. Through observation, research and experience I have come to believe that in order to adopt a concept and make it part of your everyday life you will need to go through the 5 levels of adoption: Aware, Learning, Practicing, Proficient and Mastered.
We will walk through these in a different episode, the important thing to remember is that this takes time to work through. There will be times when the organization is going to be stuck in an Aware or Learning stage for longer than you thought it should be. My advice to you, if you are in this situation, is to review all aspects of the environment and controls that you have manipulated to get to this point. Chances are that you have inadvertently introduced multiple concepts that everyone must adopt and each concept requires them to go through the 5 levels. Granted these levels might only take half a day for some concepts, but it might take a week, a month, or longer per level depending on the complexity.
The next time you start a transformation of any magnitude, think of Roy and remember this one last bit.Patience is Required.
Thanks for reading, I’m off to buy a new set of clubs to try to fix my golf game. Maybe we’ll talk about that conundrum after we review the levels of adoptions.
Axosoft version 15.2 is here with Supertabs (and a few bug fixes you can find here)!
Supertabs are item tabs with views applied.Your tabs and views combine to become Supertabs
In previous versions, each item type had only one tab associated to it. Furthermore, views were accessible via either the views button or the Tools menu. With Axosoft’s 15.2 release, you can now create multiple tabs of each item type and more.Before and After
Most importantly, Views have been merged into your tabs. So for example if I add another Bugs tab, I can apply a view on top of it to customize it so I only see bugs assigned to me. Notice that any other views you previously saved are now located here in this context menu.Take a look at the view you can apply to your tab.
Supertabs make it easy to create a tab for each dashboard, or a tab of all items in your project with your preferred layout applied from the beginning. If you ever want to save your layout as a tab, just click the plus sign for the context menu and select “Save Current Tab.” Your saved tab will become one of the options the next time you open the context menu. To manage your tabs, navigate to Tools Other Settings Tabs.Views are now called Tabs
In versions 15.1 and older, the Organize Panel was static and did not update as you changed tabs. Now, your tab selection governs what you see. Your selected tab will also have this large blue bar indicative of your choice.Your select tab governs what you see.
We recommend creating a tab just for you, with your favorite filters and layout options for your everyday use. Also take advantage of the smart defaults tabs like Tickets or Features which are readily available from the context menu.Other Updates
A few more things! 15.2 updated the UI for Portal Security Roles and we have also introduced a path to files when grouping by project.Updated interface for Portal Security Roles
For the grouping by project paths, you notice it starts with the parent project folder and then breaks down any subfolders from here.We have the paths highlighted in yellow
Lastly in previous versions standard reports were available through the Tools menu. Now, standard reports are now available under the print button dropdown menu. However, any custom reports you built will still be under the Tools menu.Your standard item reports are here now!
That about covers What’s New in 15.2! As always, feel free to subscribe to our Youtube channel or follow us on Twitter to get the latest updates. Thanks for reading and we’ll see you in the next release.
Have you ever stated, “I didn’t know you could do that?” If so, you were not only stating the obvious, but also exposing a flaw in team formation. What would the result have been if you had known this characteristic about your teammate earlier?
Agile recognizes that people are unique individuals, instead of replaceable resources, and the highest value is achieved through interactions. People have unique physiognomies, however there are also internal characteristics such as motivational gifts, natural talents, learned skills, developmental environment, and personal passion, which can provide a much richer team experience.
Discovering these individual talents and sharing them at the team level can turbocharge interactions and lead to higher productivity. Here is an activity I have used with many people which is designed to expose these characteristics and facilitate better conversations.
Create a Personal Purpose Profile (PPP)
Starting at the Individual level, each person creates a Personal Purpose Profile (PPP) or triple P. The triple P helps people understand their uniqueness in light of the five areas of focus. Each area reveals a different aspect of individuality and presents opportunities to connect with people.
Write PPP at the top of a paper and get ready to create a deliverable which will be a panoramic look at your life. It can be text-oriented or graphical, black and white or more colorful.
In researching how people communicate and collaborate over 25 years, there are 7 responses or motivations that are regularly displayed during events, scenarios, or interactions. In addition, these reactions show up in people from an early age more like a gift rather than learned behavior.
Each person will typically have one main motivational gift, but can demonstrate some or all of the 7 gifts outlined below. This helps answer “Why don’t others see things the way I see them?” Here is a working definition – an individual’s first reaction when presented with an event, scenario, or interaction.
The 7 gifts and brief definitions are as follows:
- The Perceiver sees life as all or nothing, right or wrong, and there is no gray area.
- The Servant seeks to help with any situation.
- The Teacher desires to share learned information.
- The Encourager wants to give courage to people.
- The Giver looks to invest time, talent, and money.
- The Ruler understands the big picture and needs to control it.
- The Compassionate is sympathetic to people’s issues.
Do any of these sound familiar? Take a few minutes to examine these gifts and make a few notes, drawings, or doodles on the paper, which identifies your top motivational gifts.
The next portion of the triple P is natural talents. These are talents that have been a part of you for as long as you can remember. For example, some people are talented in a form of the arts like drawing, dancing, singing. Others might have outstanding academic aptitude in math or science, etc. Others may have outstanding athletic ability in a sport. Statements like “you are a natural” or “this comes easy for me” will help to illuminate these as you think about them.
Take a few minutes to continue your triple P by documenting any of your natural talents.
Next, is the area of learned skills. During life, there are many opportunities to gain knowledge and occasionally these will develop into valuable learned skills. Examples of these are computer skills, language skills, team skills, and even agile skills. Skills can be learned formally or informally and validated by degrees, certifications, or accreditations. Learned skills might listed on a resume or CV.
List your learned skills on your triple P.
Each person was born and raised in a particular part of the world with it’s own culture, language, food, clothing, and overall lifestyle. These make up a developmental environment. Although it might not be where you are living today, the background will potentially influence your interactions with others.
In our busy world, there are many activities that consume time. Most of these are “need to” type scenarios, however somewhere in the 3D arrangement of life is a personal passion waiting patiently to be done.
This could be called a hobby or form of relaxation. However it will usually be related to the question: What would you do if could do anything in the world? Examples could be spending time with pets, athletics, social endeavors, kids, community, etc., etc., etc.
Now that you are dreaming of doing it, draw a picture or write a story about your personal passion on your triple P.
Share Your Uniqueness
Celebrate how unique you are and start sharing your triple P. Don’t wait for someone to say, “I didn’t know you could do that?” Start with your co-workers and begin to recognize the benefits of knowing your team better. With each passing day, there are interactions that could be improved if the participants knew more background information. It’s amazing how the smallest piece of information can spark a large conversation leading to enhanced communication and collaboration.
Agile recognizes that people are unique individuals, instead of replaceable resources, and the highest value is achieved through interactions. Creating and sharing a Personal Purpose Profile (PPP) containing motivational gifts, natural talents, learned skills, developmental environment, and personal passion should be a part of your agile transformation activities.
It’s time to have a team meeting and turbocharge your interactions.
Find out how VersionOne can support your turbocharged teams.
Kelly has more than 25 years of experience in the software industry and 19 years working with agile practices. As an agile program manager, ScrumMaster, agile coach, and VersionOne administrator, Kelly has helped create successful products in the desktop, dot com, and mobile space for the airline, hotel, rental car, rail and cruise industries. As a thought leader, he is always looking to refine processes with continuous improvement while stimulating innovation.