Many people ask, what is the distinction between an Agile adoption and an Agile transformation? The former being the adoption of an Agile method and tools, and the latter encompassing those plus the people, culture and mindset shift that must accompany the adoption for an organization to fully realize the benefit.
The real difference between adoption and transformation is that adoption fails and transformation sticks. You don’t really choose one over the other – people that fail to see the difference often do the adoption because they don’t realize that culture is what makes it really stick. Most organizations start with the adoption of a method at the team level within IT. Some will also covey the message to ‘do Agile’ from the top. However, this type of adoption rarely sticks. Middle management is lost in the shuffle, often just waiting out the change and expecting it to fail. The focus is on processes and tools – not people and interactions. The mindset of transparency, adaption and continuous improvement is misplaced in favor of mechanics and metrics.
A true transformation requires the organization to think and ‘be Agile’. It requires the organization to look at their people, organization and culture, as well as their process and tools. An organization will move through stages improving and absorbing changes in these areas. Typically, an organization will begin with a pilot with one or more teams. This allows the organization to best see how Agile will affect the current process and roles, and help to uncover gaps and potential areas of conflict, such as, central versus decentralized control.
It takes time to move through all the stages that are mapped out for the process, and much depends on the attitude and behaviors of leadership. Does leadership model the behavior they seek in others? Do they look to break down barriers to value delivery? Do they reward the team and system success rather than individual or functional success? Another important factor is that the organization knows what it is driving towards. This vision and accompanying goals are what will drive the pilot and future transformation activities. This alignment is the first step. As CC Pace continues to work with companies through this process we see the positive effects gained throughout each organization.
If you are interested in learning more about Agile Transformations, join us on Tuesday, June 13, for a free webinar on the topic! Click here to register.
Last month I wrote about how transforming your organization from waterfall to Agile is like being on a diet (here). For me the next question is what kind of diet do you want to be on; or where do we start with our transformation?
As someone who has worked with countless teams to help them implement Scrum, I am always encouraging organizations to look beyond the team. Organizations need to do more than just teach their teams how to follow good Agile practices. They must walk the talk, and start following Lean-Agile practices themselves. The Scaled Agile Framework (SAFe) supports whole organization transformation.
What I like about SAFe, is it addresses the concerns I hear most often. Concerns such as: What do we do about our PMO? How do we handle CapEx/OpEx? How do we “control” a project reporting on its progress and tracking?
While SAFe may scare some small organizations with its “Big Picture” on the landing page. SAFe really isn’t scary at all. The SAFe framework gives you everything you need to consider to transform your organization from waterfall and a project-driven focus to using Lean-Agile methods to deliver solutions.
As with any change, start with leadership. Lay the foundation for success, and bring the entire organization along for the journey. For very large organizations, just expand the big picture from its three-layer default (Team, Program, Portfolio), and you will see the newer Value Stream layer. The Value Stream Layer will be a necessity if you have very large solutions with many hundreds or thousands of team members working to deliver a solution, but has many roles and concepts that will support even smaller organizations. Most notably for everyone is the article on keeping an economic focus.
SAFe is a diet for transforming your organization that given the basics of eating healthy, also provides a pick and choose menu so that each organization will have what it needs to be successful. If you haven’t taken a look at SAFe 4 with the added layer for managing Value Streams, I encourage you to do so. As for us old-timers it’s hard to find fault with a framework that supports all that Scrum has to offer at a team level, while addressing the rest of the organization giving us tools to ensure a successful Agile transformation.
Have you heard that not all Agile Transformations are successful? Have you wondered what makes some transformations more successful than others? Are you wondering if your organization can be successful?
Here is a little analogy to think about. I recently lost 40 pounds on an eating transformation plan, or more simply a diet. I don’t like to call it a diet, because if I ever go back to my old way of eating I’ll likely gain my weight back. Also if I don’t follow the basic guidelines of the diet, I may not lose weight at all. So what does this have to do with being successful at Agile?
When organizations pick and choose what principles to follow in Agile, it’s like low carb dieters choosing to still eat potatoes, or white bread on their diet. While they may see some improvements, overall they are not setting themselves up for success on this plan. The diet gets blamed rather than how the dieter chose to implement the diet.
When preparing for a transformation, the first step is to get the foundational pieces right. Learn about the plan. Prepare your house by cleaning out your cupboards and fridge, and shop for the good stuff to replace the bad stuff. Learn what the rules of your plan are, and set a date to begin. Note, a new eating plan works better if everyone in the house is on the same plan! Then measure the results, and make corrections as needed.
In an Agile transformation, the steps are much the same. Identify what method you want to follow within the Agile framework. Get everyone onboard by helping them learn about the methodology. Prepare your “house” by looking at the organizational structure and identifying what will work within the transformation and what won’t. Make a decision to replace the practices that don’t fit in the transformation with practices that will support a successful transformation. Inspect and Adapt to keep improving and making course corrections along the way.
So what if your organization doesn’t want to follow the plan to the letter? It’s OKAY… BUT the organization needs to know the impact of alterations in the plan. If I can’t give up my potatoes what does that mean? Will I see the same success rate? How can I compensate for keeping my potatoes?
Some Agile principles are more easily adapted than others. I can counteract teams not being co-located for “face-to-face” interactions, by providing great tools for them. I can bring those team members together for planning sessions, or other occasions to help build the team rapport, and offset the lack of co-location. Other principles aren’t so easily adapted. A poor company culture where trust and empowerment are lacking, may prove to be too much to overcome, leaving the organization with unmotivated and un-empowered teams.
If your transformation has hit a plateau, or doesn’t seem to be working. It may be time to take a look at how you are following the new plan, and where your potato-eating cheats are causing you bloat, and derailing your success. It may not be the method, but rather how you are following it.
I’m just returning to work after Spring Break in Cancun. I’ve met some lovely people while enjoying the sunshine. As I chatted with those beside me at the beach and alongside the pool, two common questions are asked: What is your name? and What do you do for a living? The answer to the first question is easy, but the answer to the second question is much longer. Why? Because I can’t just stop with “I’m a trainer”. I enjoy talking about Agile and Scrum, and explaining the basic framework. I enjoy sharing with others how they can apply what I teach to just about anything. I enjoy sharing Agile stories because Agile works, and I like talking about how companies can adopt an Agile mindset.
When I start talking to someone about Agile, I begin by explaining first how past processes have fallen short. The trials and tribulations of a 1 or 2 year project plan, managing risk, reaching or missing milestones, and change requests to re-baseline the plan for any number of reasons come to mind. All with a real concern of delivering something that misses the mark in “delighting the customer”. Waterfall projects often have cost overruns, extended delivery dates, and a plethora of change requests that aren’t discovered until near the end of the project during User Acceptance Testing (UAT). For these reasons, Waterfall just doesn’t feel like the best choice to deliver software anymore.
I then move on to talk about why I, and so many others, choose Agile processes to build software today. So here is a little of what I talk about:
- Continuous engagement with the customer and other stakeholders is key
- Seeing progress through continuous delivery enables better feedback
- Reduced risk and waste, which can save money and heartache
- Adapting to change quickly, which allows for the customer to respond to market changes
- Better quality deliveries by testing early and often
- Happier employees as a result of practicing the 12 Agile Principles
It isn’t magic, and it isn’t necessarily an easy transition to make. To become a truly Agile organization takes a true shift in how we and everyone else in our organization thinks about how work is performed both internally, and externally with our customers.
Yes, I am a bit of an evangelist. Sometimes I want to shout from rooftops “people get it together, follow Agile principles”, “walk the talk”, “quit being stuck in the past”. Our world is evolving every day. To keep pace with our competitors, we need to evolve too. Agile is an umbrella term for a number of methodologies including Kanban and Scrum. Today we find that Agile isn’t just for software anymore. The principles and methods can be followed just about anywhere to greatly improve our ability to deliver just about anything. That’s why I’m not just a trainer, but a believer.
No matter what kind of work we do, we look for feedback from our customers, our co-workers and our peers. Why do we do that? To improve and to get better at what we do. The same thing applies to Agile teams and programs, no matter what methodology the team is following: Scrum, Kanban, XP, SAFe, LeSS or DAD.
A good retrospective is the key to helping teams improve what they are doing. It helps them identify and streamline processes which can create efficiencies and get them to that next level of maturity. Hard to believe, but this is the event which is most commonly ignored or is taken lightly. Teams often feel they are too busy and do not have time to retrospect. This makes the team get into a Plan and Do – Plan and Do vicious cycle. They never stop to reflect and adjust and then they complain Agile doesn’t work.
An Agile Methodology isn’t magic and it doesn’t solve all problems by itself. It makes the problems transparent and clear and appear sooner in a project’s lifecycle. But to identify the problems and to find out what can be done differently to improve the processes, the teams need to retrospect.
So why don’t the teams do retrospectives? Here are some of the reasons they give:
- Don’t have time just to talk, it’s a waste of time
- Retrospectives are boring
- No one takes any actions from the retrospectives so why bother
- Same monotonous technique
- Unplanned meeting
- High performing team already, nothing more to improve on
- No participation
So how do you make retrospectives interesting, add value to the team and make them a place where the team members can express their opinions without any repercussions?
First of all, the retrospectives should follow the Vegas Rule – What happens in Retrospectives stays amongst the team members. All of the information is shared in this container of trust and all team members and facilitators should respect the container. Information or data in the retrospectives is collected with the sole purpose of making the team better and improving processes. The information should not be used as performance management feedback.
Secondly and most importantly, it is not intended to be a finger pointing session or to point out the skill or knowledge gaps in any individual team member. Retrospectives should always be respectful and be conducted professionally by a skilled facilitator (usually a Scrum Master).
Thirdly, the retrospectives should be done by selecting interesting activities that engage all team members. The activities should be relevant to what is happening in the team. Retrospectives should enable the entire team collect data, learn the insights and decide on what actions they can take together to improve.
Fourthly, the retrospectives should be made exciting. The team which asks the same dreaded questions – what did we do well, what did we not do so well and are there any suggestions for improvements at the end of every sprint usually don’t get to the crux of the matter. The retrospectives get boring and monotonous.
Create an environment of trust and honesty and make room for some creative insights. Retrospectives should be planned in advance so the team feels like it is a pleasure being part of the retrospective after all the hard work in the sprint. It should allow the team to think about innovative ways in which they can adjust and make themselves and the processes better. A book by Ester Derby on ways to use creative exercises in retrospectives is an excellent resource and so is the website Tastycupcakes.org.
Next, what about the findings and action items from the retrospectives? Many tools like Version One have a section wherein the retrospectives can be created, stored and referenced in the next retrospective. The best thing is to prioritize the items, assign them owners and place the list both in the online tool for distributed team members and on the Physical board as an Information Radiator. Do a check-in on the retrospective action items and see if they are completed. Retrospective items can be added to the team’s backlog and be accepted by the team’s PO.
Just collecting feedback and forgetting about the retrospectives is what makes most people discouraged from holding retrospectives. When people feel that no action is taken and nothing changes, they wonder why they should keep on wasting time with this retrospective exercise.
Participation from all team members is key. Especially if you have some very quiet team members and others who have a lot of ideas and take over the meeting. Good facilitation skills come in handy to address this concern. If the facilitator knows that some team members will not jump in and be part of the conversation, they can ask direct questions to engage those team members so that everyone is heard and valued.
Lastly, no team is so high performing that they cannot retrospect or find anything else to improve. They might have found other mechanisms of inspecting what they are doing and how to adjust, that they do not wait until the end of the sprint for this formal retrospective session. These teams have learned that improvement is always something to look forward to.
A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.
Here are 10 tips to keep in mind when helping teams in their transition:
Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size. And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.
If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points. It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.
Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it. Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.
Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself. It takes me a week. Assuming we’re taking the same route, and driving the same speeds, why is there a difference? It turns out that my friend can drive 12-13 hours a day with minimal stops. Whereas I start falling asleep after 2-3 hours and have to stop frequently. So it takes me longer (duration) to do the same amount of work (effort).
Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months. Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days. Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.
For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”. What others often hear is “it will take someone a week to do this”. I’m talking about effort; others are hearing duration.
The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours. But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.
Don’t define story points in duration-units and expect it to correlate to effort.
Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate. Use commitment based-planning and have them track their story throughput rather than points or hours. As they become more comfortable with this, stories will begin to creep smaller and smaller naturally. Check out more about the #NoEstimates movement.
Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it. Opt for shorter iteration lengths, as this will offer more opportunities to practice.
If teams are thrashing, there may be too many changes happening at once for them to absorb. We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.
Focus efforts on improving the ability to create vertical slices of value.
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating. Strive for small stories using story-splitting techniques. Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback. Smaller stories also improve the flow of work.
As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other. A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration. Mature teams will often have stories that take around one day, and all their stories are of similar size.
Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.
And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work. Forget the “if you challenge them, they will rise to the occasion” call to arms. After a certain point, that’s just a bunch of malarkey.
As my grandma used to say, “You can’t get blood from a turnip”.
I spend a lot of my time coaching individuals, teams, and organizations interested in reaching higher levels of performance through the use of Agile methodologies like Scrum, Kanban and SAFe. Some clients expect me to tell them what to do step by step, while others are interested in learning how methods work so they can determine what practices to use as their circumstances evolve. The approach that leadership teams prefer usually reflects the problems they are trying to solve, as well as their domain of expertise, their size, their culture and their organizational purpose (for-profit, non-profit, government, etc).
In conversations with leadership teams, we discuss patterns and practices they could help institute or amplify in order to sustain their Agile transformation journey. Our message, reinforced by all success stories in the industry in the last 15 years is clear: The success of an Agile transformation, regardless of the practices adopted, is directly proportional to how well people in leadership roles at all levels understand, exercise, and constantly improve their Agile mindset.
Leading with an Agile mindset means letting go of the traditional notion of leadership as strategy and control from the top according to a pre-determined plan of action. In times of rapid change when high levels of complexity and uncertainty are the order of the day, leaders can no longer assume they can know or control what goes on. Individuals at all levels must adapt constantly to changing conditions using their best capabilities and judgments in the moment.
In these circumstances, the role of leadership in Agile organizations is to shape the understanding, development, and learning of team members so they can act both independently and in concert with the goals of the whole organization. Leaders need to become coaches, coaching across the organization as well as individuals:
- Individual Coaching: You institute a style of leadership that is participative, servant, transparent, and unleashes the intrinsic motivation of a workforce that seeks mastery in their respective skills
- Organizational Coaching: You focus on understanding and managing the organization as a whole, optimizing the interdependence of teams and departments in order to minimize waste and maximize effectiveness
In practice, we observed that effective leaders in Agile organizations are also effective coaches. I constantly meet people who have a natural coaching mindset and they don’t even think of what they do as coaching. Here are three definitions and models of coaching that have emerged in recent years:
- Coaching is a process that enables learning and development to occur and thus performance to improve. To be a successful Coach requires knowledge and understanding of process as well as of the variety of styles, skills, and techniques that are appropriate to the context in which the coaching takes place.– Eric Parsloe, The Manager as Coach and Mentor
- Coaching is unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them. – John Whitmore, Coaching for Performance
- Coaching is an interactive process through which managers and supervisors aim to solve performance problems or develop employee capabilities. The process relies on collaboration. – Richard Luecke, Coaching and Mentoring
Leaders in Agile organizations understand that coaching creates a learning environment where individual and collective challenges are the first priorities. Coaching skills enhance their management tool-set in a way that benefits themselves, their staff (those who are coached), and their organizations.
Trust – The Foundation of a Coaching Relationship
Trust has been defined by some as the ability to be vulnerable (Schooman, Mayer, and Davis, 2007). Implicit in this definition is the assumption that when you trust someone, you’re willing to be open, less guarded about your weaknesses and more candid about your opinions and ideas.
In his 1993 dissertation, A Construct of Trust, Dr. Duane C. Tway, Jr. defines trust as “the state of readiness for unguarded interaction with someone or something.”
And in Rhetoric, Aristotle, 384-322 BC), suggests that Ethos, the Trust of a speaker by the listener, is based on the listener’s perception of three characteristics of the speaker: competence (correctness of opinions), character (reliability – a competence factor, and honesty – a measure of intentions), and the goodwill of the speaker (favorable intentions towards the listener).
When a manager uses a supervisory approach, the relationship between the manager and their subordinates is based on expertise. Boundaries are strictly maintained. Trust, while relevant, is not a key component. The relationship is embedded in the hierarchy of the organization.
When managers coach, the relationship between them and their subordinates is based on both expertise and on abundance of trust. Subordinates trust their managers to do the right thing for them, for themselves, and for the organization.
Samuel B. Bacharach, director of Cornell University’s Institute for Workplace Studies conducted extensive research and wrote over twenty books on management, organizational behavior, and industrial relations. His research indicates that organizations that do not embrace a coaching culture perpetuate a static culture of inertia, bureaucracy, and control. In contrast, coaching is a characteristic of organizational cultures that value innovation, creative thinking, problem solving, growth, and change.
Bacharach points out that “a coaching relationship requires that the protégé (the person being coached) views the coach as someone who possesses the expertise of a good supervisor, but who is simultaneously as trustworthy as a good friend. This combination of expertise and trustworthiness composes the personal integrity of the coach. The more your protégés believe in your personal integrity, the more committed they will be to you, and the greater the likelihood of your success as a coach.”
In another study, C. Ken Weidner, an assistant professor at the Center for Organization Development at Loyola University Chicago, found that trust in the supervisor is associated with better individual performance.
You don’t need to be a trained professional coach in order to include coaching in your set of Agile leadership skills. You have to be able to tell your employees “I know how to do it,” or, “I’ve been there and done that,” without giving them the impression that you think you know it all. To establish or amplify trust, Bacharach recommends you let your protégés know that:
- Confidentiality is the golden rule
- You have their interests in mind when making decisions in the workplace
- They have the ability to speak freely to you
- You are open to learning new things and some of those things can be learned from them
Trust is the foundation for coaching relationships. It is also the foundation for what you want your organization to become.
The Supervisory and Coaching Mindsets
Both coaching and supervisory relationships exist within the hierarchical dynamics of an organization, yet they are fundamentally different. A coaching relationship temporarily suspends the hierarchical structure, and is a partnership based on the candid, free-flowing transition of ideas and information between coaches and their protégés, which serves to support, reinforce, and motivate both.
Coaching holds that employees potentially possess the best answers to the problems they are faced with, and that the coaching process helps them discover the sources of those answers within themselves.
Leading involves both supervising and coaching. As a proactive manager or leader, you perform each of these two different roles, and each is characterized by its own mindset. Moving between these roles requires a subtle mind shift. Here are several examples:
Let’s look at several examples of how a supervisory mindset or a coaching mindset can influence the way we communicate with others:
- “I suggest you complete your work in the order that you receive it.” – The supervisor focuses on coordinating work rather than facilitating it.
- “Since our last scheduled meeting, you’ve been doing a good job. Keep up the good work.” – This statement is an evaluation of job performance and is characteristic of a supervisory mindset. There is no suggestion of a plan to develop skills together or of a partnership, both hallmarks of the coach-employee relationship.
- “I understand the tight deadlines, the constant pressure from customers to provide the best service, and the intense competition that are all a part of your job. How do you think we can continue to improve the organization and ourselves given these conditions?” – This is a coaching statement. The speaker is empathetic and shows expertise regarding the current situation. The speaker indicates an interest in partnering with the direct report.
- “Working closely with you is very helpful, because not only do you improve on your abilities, but working with you also enables me to isolate those areas that seem problematic in general for employees in your position.” – The sense of partnership communicated here indicates a coaching relationship.
- “I appreciate your coming to me for assistance. It takes a lot for people to recognize their limitations and to know when they need to seek advice from others. In my experience, there are a few different ways we can approach solving this problem, so let’s work together to think of a feasible, realistic, and desirable solution.” – The sense of partnership communicated here indicates a coaching relationship.
Mindsets like Agile Leadership and Coaching are critical to the success of an Agile transition in your organization. It takes practice to be good at them, and that means you have to go out there and do it. If, in the process of coaching, questions or challenges come to mind, we’d be delighted to hear from you.
If you read this far, you probably enjoyed this article and I hope it stimulated ideas you can start using at work. I greatly appreciate your curiosity, and hope you stay in touch! Let me know if we should expand on this topic or if there are other topics that you would like to read about.
In a prior post, Getting Ready for Your Technical Transformation, I defined technical transformation and why it is so important. Now, I’d like to dive a bit deeper into some tips on going about it…
To begin to transform your technical ‘world’, you need to first make sure your organization’s environments are aligned. As a start, the technical experts in your organization should decide what environments are necessary to deliver the value to the customers; sometimes it could mean as few as 3-4, and sometimes 10-12 may be more like it. The idea here is to build only the environments which are required and leave the others behind; the more environments your organization has, the more attention and costs that will need to be given to them. When you have more environments, you vastly increase your costs in areas such as physical hardware, bandwidth, cloud storage, software platforms, which also calls for an increase in cost to administer and configure these environments. It is wise to plan out the environments carefully!
From what I have seen, and know from my experience as a developer, organizations can usually get by with 4-7 environments, such as “Development”, “Testing”, “User Acceptance Testing”, “Staging”, and “Production”. A couple of these may be combined or broken out in some organizations, depending on who is doing the acceptance, if there is training to be done, or if there is any beta-type testing needed, but remember that the more you have, the more work they require!
The point is to have the environments, regardless of how many you have, be aligned with the delivery, meaning “Development” would be used for team member to write code, write test scripts, etc., while “Testing” would be used to run stable code, execute test scripts, etc., with a constant set of data to check for bugs, “Staging” would be used to smoke test everything before it is put into “Production”, and so on.
Once the environments are established, the next question is what to do with them and how to move the product through them to “Production”. There are numerous ways to do this, and the ‘go-to’ way is by manually copying the product between them or even rebuilding the product in each environment. However, by doing these manual processes, the move is prone to errors—anytime you insert manual, people-driven processes, you introduce error.
In order to eliminate as much error as possible, it makes sense to have machines do the moving. This process is referred to as “Continuous Delivery”. You can make this happen by utilizing tools that are out there to help with this very thing. Some of them you may want to explore are: Jenkins, TFS, Ant, Gradle, Bamboo, or Puppet. While these are a start, there are many, many others tools to choose from. The selected tools will depend on your preference, i.e. if you are a person comfortable with scripting/coding or someone who feels better about checking boxes and clicking buttons.
These tools will help you move the product through the environments to “Production”, but they will also help you with another key aspect of transformation: continuous delivery of each product increment. To complete an Agile transformation, including the technical ‘stuff’, you really need to be able to deliver continuously to each environment.
Any organization that feels it has truly become Agile will hold to the true nature of Agile: iterative and incremental delivery. If this is the case, then it stands to reason that you need to be able to continuously deliver product, pretty much on demand.
If you get stuck and are not sure what to do, you can always call upon a Technical Agile Coach—they can help you align your environments, choose the right tools, and even get you delivering continuously!
In my last post, I talked about what a “Get It Done” (GID) pattern looks like in organizations. Today I’ll talk about another cultural pattern.
“JUST DO IT”
Many of us are familiar with “Just Do It” as a Nike ad campaign, which began in 1988…egad! I can’t believe that was over 25 years ago!
Although Nike (which, go figure, is the name of the Greek Goddess of Victory) got inspiration for their famous slogan from the final words of a serial killer (“Let’s Do It”), their ads resonated positively with the public because the simple words and imagery reflect our uniquely American values and spirit.
Be strong. Be bold. Be first. Be victorious. Do something. Do anything. Start now.
That spirit is at the heart of a JDI culture, a culture that focuses on and rewards starting. A culture that plays to our passion, our confidence (some would say arrogance), our desire to win, and our innate belief that we will prevail under any circumstances. Success and the American Dream are ours if we take action, work hard enough, and persevere. This is where we come from, it’s in our national DNA.
So what’s wrong with that, you say?
Well, there’s nothing wrong with it, exactly. It’s as American as baseball, mom, and apple pie. But is it a good fit for Agile?
I’ve worked in many JDI environments; it was exciting, I enjoyed it, and I learned a lot. Most first-responder and mission-critical jobs depend on people just-doing-it. It requires the ability to adapt and make quick decisions while not having all the facts. It’s fun, challenging, risky, and satisfying to plunge right in and get your hands dirty. What’s not to like?
But it can also be stressful. There’s an expectation to try harder, to do more, even to be perfect. There’s often an element of competition, and a feeling that if we stop to rest, we’ll fall behind. Adrenaline pumps through our body in response to the challenge of walking an ever finer edge, ready to spring into action, climb that next mountain, turn around that troubled project, or conquer the world. We have the freedom to move fast, but not the freedom to fail. Always, there’s the awareness that if we’re not up to the challenge, we’ll be seen as weak. And as President Lyndon Johnson once said, “The American people will forgive you anything except being weak.” While some of us can thrive in this kind of environment forever, for most of us it’s not sustainable for the long haul. We burn out, or wear out, over time.
Lest I be misunderstood….starting things IS important. As is passion, confidence, and the ability to adapt quickly and act in the face of uncertainty, to not be paralyzed by indecision. These characteristics of a JDI culture are also essential to Agile delivery.
It’s just that in a JDI culture, the scale tips toward the un-Agile characteristics. Like runaway WIP, because it’s more exciting to start the next new thing than it is to finish what’s already in progress. Like fatigue, because the pace is not sustainable. Like an obsession with success, because there’s a low tolerance for failure. And like an emphasis on “I can do” over “we can do”.
An Agile change initiative would certainly start with a bang in such an environment; and would likely lose momentum before finishing. An appropriate balance is needed to create change, respond to change, and sustain change. And a JDI environment is out of balance.
So that’s my story and I’m sticking to it…..what do you think?
As your organization prepares to transition to an Agile one, you will most likely want to know all that the transformation entails. One of these things will be transforming your technical practices to better align with the Agile Engineering Practices…so how can you make it a success?
Plan For It
Organizations typically will look at the process, the teams, and the projects they will transform in their move to Agile. However, they often forget a key piece of the puzzle: the technical ‘stuff’.
In the scheme of things, it is fairly easy to change the process that one is doing from process A to process B. It’s also relatively easy to choose the projects that will move to Agile and the teams that will work on them. The hiccup is that they almost always forget about the changes that must be made to the technical architecture they have in order to ensure the complete transformation.
Identifying the technical changes that need to be made and ensuring they are part of the transformation plan are keys to making your agile transformation a success!
Architecture on the Brain
In most organizations, the technical architecture is one that is usually aligned with projects or, sometimes, aligned with what was pushed and when. The architecture is most likely not aligned with the various applications or features that the organization produces.
When this is the case, the teams most likely will have a difficult time aligning themselves in a way that they can concentrate on any specific application or feature. This concept produces issues for teams’ ability to work on a defined backlog, and even worse, creates barriers to them completing anything of value during a sprint. This type of architecture is steeped in dependencies and blurry lines.
In order to ensure the architecture is set up to allow for the Agile Engineering Practices, it is imperative that the architecture be examined and plans be made to make the necessary shifts in the alignment of the architecture to match.
What About Environments?
Environments are another aspect that can cause issues when attempting to institute Agile Engineering Practices.
There are usually multiple environments, like DEV, QA, SIT, UAT, and PROD, that the team will move their completed increments through. The biggest concern with this is that most of the time, the environments do not match up and they have varying states of the application and data. This poses numerous obstacles to the team being able to produce effectively.
To deliver value effectively, teams need to be able to accurately test the stuff they are producing. In order to accurately test, they need to have a “clean” environment to move their increments into. When environments are not in sync and/or are not aligned correctly, teams will have issues creating successful builds and testing them.
When the environments are not correctly aligned and/or they are not working properly, there are major consequences that can result. These consequences can range anywhere from not completing a sprint’s increments to producing low quality results to ending up with unwanted value.
A Couple Things to Think About
If an organization doesn’t identify and plan for the technical architecture changes they will need to support their Agile transformation, they will most likely cause more delays and, more importantly, pose more barriers to the team’s effectiveness.
Examine what your team has in its way when it comes to developing, testing, and deploying code. What kinds of measures do you feel your team needs to take in order to deliver value on an incremental, consistent basis?
Stay tuned for the next installment where we will look at ways to make the technical transformation a reality…