In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives. Each agile project developing a product or a solution has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.
In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:
3. Agile Methods and Environments
6. Value Chain (see Tables 1 through 4 of Part 1 of this blog series)
Each scaling agile parameter can assume one or more values from a range of values. This comprehensive (but by no means, complete or exhaustive) list of 25 scaling agile parameters suggests that the agile scaling space is complex and rich with many choices. Each organization or large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique. However, in Part 1, I also clarified that “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise). Systems thinking is important for Scaling Agile Your Way.
In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS. Although there are differences among SAFe, LeSS and DAD, they all are radically different from MAXOS. In this part of the series, I will compare and contrast SAFe vs. MAXOS in some depth.
Briefly, here are the key highlights of SAFe. Details can be found at Scaled Agile Framework:
- SAFe requires a “Portfolio, Program and Teams” hierarchy for a large-scale agile project.
- Each team must be a cross-functional Scrum team and may follow many XP practices.
- Epics at portfolio levels are managed as a Lean/Kanban flow. Epics are broken down into features that can be completed in a single release cycle at the program level; each feature is broken down into stories that can be completed in a single sprint at the team level.
- All teams in a release train of a program must follow the same lock-step sprint cadence (typically two weeks).
- Release train planning requires all team members (typically up to 150) from all teams in a program to hold two-day-long release planning meetings in person, which entails a substantial effort and complex logistics.
- Release cycles are typically eight to 12 weeks long.
- Software is developed on sprint cadence, and released on demand (but cannot be released faster than the sprint cadence).
- Considerable time and effort is spent in various ceremonies: sprint planning, sprint review and sprint retrospectives, release train planning across multiple teams, release review and release retrospectives, etc.
Briefly, here are the highlights of MAXOS. Details can be found in Andy Singleton’s Agile 2014 presentation.
- MAXOS is the scaling approach for “Continuous Agile.” Continuous Agile combines Kanban Agile task management with continuous delivery code management.
- MAXOS requires a number of (almost) independent service teams.
- Services have well-defined APIs, are loosely coupled, and have minimal dependencies among them.
- Each team operates with Lean flow. Applications are rapidly composed of a group or a network of services.
- Each team is developer-centric (not cross-functional) and highly empowered.
- Code is continually integrated in a single code base across all teams.
- Code is continually tested with automated tests (unit, acceptance, regression, etc.) by firing off as many virtual machines as needed in a cloud-based environment.
- Any dependency issues across teams are immediately resolved via rapid team-to-team communication. For rapid team-to-team or member-to-member communication, tool support is essential. VersionOne provides excellent communication and collaboration among team members.
- The typical ratio of developers to testers tends to be 10:1, as teams are developer-centric and developers do most automated testing. There are no separate QA teams. QA testers are called as needed for their expertise by developer-centric teams.
- Each empowered, developer-centric team decides when to release its code (not decided by QA testers or product managers!). MAXOS claims that this policy rationally aligns the interests of developers with consequences of their release decision; poorly written, poorly reviewed, or inadequately tested code may mean “no weekends” or “No Friday evening beer” for developers!
- All features or stories have switches (togglers) that the product owner (called story owner) decides to turn on (unblock) or turn off (block) based on the market needs.
- Code released in production is extensively supported by automated user feedback collection, measurements and analysis that result in actionable reports for product management.
- Automated feedback from production environment is also used directly by developers to immediately fix problems.
- Meeting time is minimized by “automating away” management meetings, and removing or reducing other Scrum ceremonies. For example, sprint and release retrospectives are replaced by periodic “Happiness Surveys” and taking actions based on those surveys.
Because of these fundamental differences between SAFe and MAXOS, they represent radically different approaches to scaling agile. The contrast between SAFe and MAXOS is breathtaking, and its implications are worth understanding. Tables 5-10 present the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.
These six tables (Tables 5-10 below) follow a specific color legend described below:
Are your agile projects closer to the SAFe Sweet Spot or the MAXOS Sweet Spot?
Or are your projects closer to the SAFe Challenge Zone or the MAXOS Challenge Zone? Or are you in a situation where neither SAFe nor MAXOS will serve you unique agile scaling needs? If you are exploring the use of LeSS or DAD framework, I would encourage you to use the list of 25 scaling agile parameters to identify the Sweet Spot, Challenge Zone and Unfit Zone for LeSS or DAD (as I have done in Tables 5-10 for SAFe and MAXOS). Then determine if your projects are closer to the Sweet Spot or Challenge Zone of LeSS or DAD.
Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly
Stay tuned for these future parts of this series:
Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS
Part 4: Scaling Agile Your Way – How to develop and implement your custom approach
We should all be much more active about improving our communication skills to be better at our jobs, but also (and more importantly) to make the most of the people around us. Whether you’re giving or receiving information verbally or through writing, no matter what your job is, communication is key.
A new approach to projects or a new tool is not a quick fix or a silver bullet. Too often, you have ingrained, systemic problems that require a cultural change. That doesn’t mean a new approach or a new tool won’t help. It can. But you also need to adjust the environment that caused the problems in the first place.
Software vendors are making extraordinary efforts to protect the installation and use of apps, but have they gone too far? Preventing software piracy can have an adverse effect on genuine users. Software licensing technology, according to Steve, needs to strike the best balance of protecting the asset while trusting the customer.
Rally Onboarding Bootcamp: Class of June 2014
“Rally truly practices what it preaches. Volunteering at There With Care touched my heart and made me proud that the company I work for is helping such a wonderful organization. It was amazing how we pulled together as a team and incorporated our Agile training from earlier in the day into our give-back project.” — Terri Barrowcliff, Customer Relationship Manager, Rally Onboarding Bootcamp, June 2014
During my first year at Rally, we’ve experienced exciting growth as a company. When I started in August 2013, we had about 400 people worldwide. Today, we’re over 500 and still growing. With so many people joining the company, we’re continuously refining our onboarding process — adapting it to focus on what newcomers really need to know to succeed at Rally, and introducing a strong dose of company culture. Each month, new employees from around the globe come to our Boulder headquarters to experience Onboarding Bootcamp, Rally style.
Giving back to the communities in which we live and work is among the values on which Rally was founded and holds dear (see 1%: Small Percentage, BIG Impact). Another of our core values, as you might expect, is to Live Agile. So we challenged ourselves to combine the two: create an impactful community service activity that instills the importance of giving back our time and talents that’s also a hands-on learning opportunity in Agile practices.
I reached out to Jodee Spalding, Volunteer Director at There With Care, a Boulder-based nonprofit organization that provides fundamental support services to families and children facing critical illness. I knew that There With Care relies heavily on volunteers to deliver its services and found a willing partner to customize a program for Rally. With Jodee’s help we quickly identified an important need that Rally could fulfill.
“Easy Meal Care Bags are essential to the parents and caregivers of children being treated in the hospital. Instead of leaving for meals, loved ones can stay at the child’s bedside to provide comfort and support, and ensure they don’t miss an opportunity to speak to the child’s doctor. Now that Rally is sending volunteers once a month to create the bags — and funding the cost — we are able to replenish them as needed, and the families are so grateful.” — Jodee Spalding, There With Care
On their first day of Rally Bootcamp, new employees spend two hours with our Agile coaches learning about Agile concepts, methodology, and practices. Later that afternoon at There With Care, we ask the new hires to practice some of those concepts — such as self-organizing teams, collaboration, and inspect/adapt — when assembling the Easy Meal Care Bags. We provide the product requirements and let the team decide how to get the job done, with the following guidance:
- Take time to plan the work and organize as a team
- Focus on quality and process, more than on quantity and speed
- Limit work in progress (WiP) and watch out for bottlenecks
- Respond to change over following a plan
- Consult the Product Owner (Jodee) as much as needed
- End with a retrospective — what did we learn and what could we do better next time?
Rally Bootcamp participants conduct a midpoint review while assembling Easy Meal Care Bags.
Since February, 134 employees have volunteered at There With Care, contributing a total of 201 hours and creating 425 Easy Meal Care Bags weighing in at 3,188 pounds of food and drinks — lovingly delivered to parents stationed at the bedsides of their critically ill children. A grant from the Rally For Impact Foundation covers the cost of the bag contents, which has totaled nearly $5,000 since the partnership started just nine months ago.
“Just as meaningful as the grant is Rally’s donation of more than 200 volunteer hours from new groups of big-hearted Rallyers lending their compassion each month. In appreciation, we’ve honored Rally with our Inspiration Award, presented to individuals and community partners that have contributed outstanding service to There With Care’s mission.” — Jodee Spalding, There With CareGeri Mitchell-Brown
When one organization first shifted to agile, the team had trouble with maintaining the product backlog. No one could agree on priorities for items, they didn't know which item should be groomed next, and the backlog wasn't transparent to everyone. This team found a better method that works for them.
This post, an interview between Grokky co-founder Dan Abdinoor and Rally engineer Andrew Homeyer, originally appeared at the Grokky blog on September 8. Andrew is product lead and engineering manager of Waffle, a Rally Innovation Labs project created in 2013. Andrew currently manages a team of six and his manager is Rally’s Chief Technology Officer.
Dan: Andrew, please introduce yourself!
Andrew: I’m an intrapreneur and engineer. As for titles I sometimes go by Chief Waffle Maker. In truth, I balance my time between leading the team building Waffle.io and trying to still do a bit of development myself.
Dan: Waffle is part of Rally Software; what's the story behind that?
Andrew: Waffle.io is an Enterprise Lean Startup; that is, we’re a small team building Waffle like a startup inside Rally Software, following lean startup principles. We’re a team of six today, distributed between Boulder, Colorado, and Raleigh, North Carolina. But our humble beginnings go back to the summer of 2013 when Waffle started as a team of interns, exploring a new market segment for two months.
Dan: How has your management style evolved from when you started Waffle?
Andrew: To borrow from Reid Hoffman’s The Start-Up of You, I’m always iterating on myself. My management style changes every time I interact with different types of individuals, to meet them where they are and to make my team the most effective it can be together.
Recently I’ve been learning from Dan Pink’s ideas of Autonomy, Mastery, and Purpose, taught to me by some great leaders at Rally. What does it look like for you to discover the internal motivation for your team members? What drives them? These questions have caused me to change the way I interact with my team.
Dan: How do you run your one-on-one meetings?
Andrew: First rule of 1:1 meetings is to be consistent, and frequent. I do them weekly, for both remote and local team members. You start building trust and respect, one of our core values, when you put the time into it. Even when there aren’t any burning topics to discuss, it’s worth the investment of a 20-minute meeting every week.
As for the structure, I try to shy away from talking about the work we’re doing. In some cases that’s what we discuss; but talking about team dynamics, personal goals, frustrations and excitements — those are the things that help me discover what someone cares about and how to make our team more effective together.
Dan: What are some of your management suggestions for others?
Andrew: There’s a difference between technical leadership and people leadership. If you’re managing others, make that separate from your role of technical leadership. Yes, mentor others when you’re more experienced and capable at certain things. But, when I’m wearing my people management hat, my goal is to help someone discover what skills they want to nurture and how they can best contribute to the team’s shared vision.
Management ties closely to hiring. If you hire well, it changes how you manage. The question I ask myself when hiring someone is whether they currently are, or have the potential to be, better than me in some given role. If that’s true, then the role of leader becomes to uplift their skillsets or mentor them to fulfill their potential.
I always put the person first. It’s a careful balance between meeting business objectives and a person’s desires, so hire and fire based on building a team that can have that overlap. If you can encourage an individual based on their internal motivation, and help them achieve their personal goals, your team and business will benefit from their dedication and commitment.
Dan: Have you ever had a moment where you felt that you had completely failed as a manager? What have you learned from it?
Andrew: Sure. Several times come to mind when I’ve decided to take personal responsibility for a piece of work, because I’m not satisfied with the quality my team produced. It usually builds frustration and distrust, when I should work with the team to figure out how we can produce better quality work on the right schedule together. One way we work towards this is with a high focus on pairing, whether it be on code or non-dev work. It’s a great way to improve quality and share learning.
Dan: What challenges are you still figuring out as a manager?
Andrew: Realizing that everyone is unique, and not motivated by the same things. How do you create a shared vision that each person takes personal responsibility to accomplish?
Also, I’m always looking for ways to work with remote team members better. Travel helps; if you don’t see each other face-to-face often enough, you forget who they are as a person and it’s easy to jump to blame when things go wrong. It’s something I try to be aware of and work towards improving.
Consider these five very different types of organizations:
1. An organization with fairly hierarchical management structure, traditional Project/Program Management Office (PMO) trying to transition from traditional waterfall development to agile development. Some teams have just a few months of experience with Scrum, and perhaps worked with few XP or Lean practices. Budgets are done on an annual basis. Senior management pays lip service to agile transformation and treats agile as a silver bullet.
2. A government contractor is used to delivering projects on a fixed-price basis. The government agency has now asked the contractor to use agile methods for large-scale agile projects.
3. The CIO and CEO of an enterprise are strongly committed to agile-lean development and have given a top-down marching order to follow agile methods. All teams have been ordered to follow a two-week iteration cadence, while members of some teams come from an offshore outsourcing vendor.
4. A company has found that their main competitor will be Amazon.com. The release cycle for most of its IT projects is six months, and they know that unless they drastically reduce this, Chapter 11 is not far away.
5. A startup company realized that unless they validate their assumptions about who the real customers are, and what the real needs of real users are, they have no viable business. They decide to follow the Lean Startup method by rapidly developing a series of Minimum Viable Products (MVPs) in rapid succession. Even after the first release of the product, the company must stay ahead of competition and deal with rapid changes in market conditions.
With the vast diversity of organizations and their projects, a cookie-cutter approach (or prescriptive recipe for all types of projects and situations) will not work. Each agile project developing a product or solution has a unique context: assumptions, situation, team members and their experience and skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.
Many agile development teams now have some experience of team-level agile practices using Scrum, XP, Lean, Kanban or Scrumban frameworks. Some of these organizations have experience with Scrum of Scrums (that is, two to as many as nine Scrum teams working together on a product or solution). These teams and their organizations are now setting their horizons to undertake large-scale agile projects where several (10 to 1,000) teams must collaborate to implement the common vision of a product or a solution.
In the last few years, there has been increasing interest in scaling agile-lean methods beyond individual teams or Scrum of Scrums to programs and portfolios of teams, as well as being able to compose new applications by stitching together a set of services developed by independent teams. The recent Agile 2014 conference had numerous presentations on the topic of scaling agile. I attended as many of them as my schedule allowed, and caught much of the rest as recorded sessions.
Many of these sessions raised the issue of ‘which scaling agile framework is best?’ I came away thinking that every large-scale agile project creates a unique situation. To tackle this question, there are really two broad approaches you can take to select the right agile-lean process for your project:
APPROACH #1: Select a well-known, scalable agile framework listed below.
A. Scaled Agile® Framework (SAFe™) by Dean Leffingwell and his associates at Scaled Agile Inc.
B. Large-Scale Scrum (LeSS) by Larman and Vodde
C. Disciplined Agile Delivery (DAD) and Agility at Scale by Scott Ambler and his associates
D. Matrix of Services (MAXOS) by Andy Singleton
If necessary, extend or adapt or customize the framework to suit your unique needs. As you gain experience, inspect and adapt for ongoing refinements and further customization. “Scaling Agile Your Way” does not mean that each new large-scale agile project must develop its own agile processes from scratch.
APPROACH #2: Develop a customized approach from scratch.
Or, if your project has truly unique needs that cannot be satisfied by any available framework (such as SAFe, LeSS, DAD, MAXOS) even after customization of the framework, you may need to develop a set of new processes from scratch customized to your unique needs, and then sustain and maintain those processes.
In many organizations, not many in-house people have this kind of expertise that would actually work. Moreover, this approach would be expensive and may not be cost-effective. As such, this approach to large-scale agile projects should not be undertaken on the ground of ideological purity, but should be based on solid business reasons.
This blog series is not a tutorial on or an in-depth review of SAFe, LeSS, DAD or MAXOS. I will provide a brief overview of these frameworks for getting started. I will then present a set of 25 scaling parameters (organized into 6 scaling aspects) that need to be considered to decide what scaling approach and methods are best suited for your specific situation, and what kind of customization will be needed.
SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects. It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners. SAFe is a proven and publically available framework for applying agile-lean practices at scale. Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe. I will cover SAFe’s Sweet Spot, Challenge Zone and Unfit Zone, and give examples of how to customize SAFe for your situation in this blog series.
SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects. In some situations, SAFe is a good fit (Sweet Spot), while in some other situations, SAFe may be in a “Challenge Zone” where some effort (such as enhancement and customizations) will be needed to overcome those challenges. But even with that effort, you may be better off using SAFe, compared to developing your own set of agile processes and practices from scratch. However, in some situations, SAFe may be in an “Unfit Zone,” i.e., it is either not applicable or will not work well. Full disclosure: I am a certified SAFe Program Consultant (SPC).
MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams. All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment. MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and Edmunds.com. MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology). MAXOS offers a radically different approach to scaling agile compared to SAFe. MAXOS also has its own Sweet Spot, Challenge Zone and Unfit Zone, as I will explain in this blog series. The Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS are very different. The contrast between SAFe and MAXOS is breathtaking. If your competition has started to use MAXOS and you are still using SAFe, your competition couldn’t be happier! On the other hand, if you insist on using MAXOS in situations where SAFe excels, you would be making a poor decision. Many practices from MAXOS (such as test automation and continuous integration) can be incorporated within SAFe.
At present, MAXOS doesn’t seem to have formal training and certification programs. I attended MAXOS presentation by Andy Singleton at the Agile 2014 conference, and have reviewed most of the public information about MAXOS, including the eBook on Continuous Agile method.
LeSS: LeSS is regular Scrum applied to large-scale development. A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions.
DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues. The DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable. DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.
Although there are differences among SAFe, LeSS and DAD, those differences are dwarfed by their differences from MAXOS. For example, while SAFe, LeSS and DAD are predicated on cross-functional teams with a number of meetings required, MAXOS advocates developer-centric, highly empowered teams (developers, not QA, decide to release!), and “management automation” to eliminate many meetings. As LeSS and DAD are not as popular as SAFe at this time, I will not cover them further in this blog series.
You can use the Agile Scaling Knowledgebase (ASK) decision matrix to access a template for comparing SAFe, DAD, LeSS and other scaling agile frameworks.
SAFe and MAXOS cover a fairly large territory of vastly different types of large-scale agile projects. Once you understand SAFe and MAXOS, and your own unique situation, you may be better off using one of those (with appropriate customizations as needed), rather than creating one from scratch and sustaining your own custom agile processes (an expensive and risky proposition).
There may be unusual situations where neither SAFe nor MAXOS may be a good fit for a large-scale agile project. I will cover this topic in Part 3 of this series. If you believe that your large-scale agile project has unique requirements that render both SAFe and MAXOS totally useless, and you have no choice but to create, maintain and sustain your own custom processes for your large-scale agile project, please let us know. I would be very interested to know about your unique situation and what led you to prefer custom processes from scratch.
Customization approach: Scrum at Scale meta-framework developed by Jeff Sutherland and Alex Brown starts with the basic premise that Scrum is an object-oriented framework. Scrum at Scale framework is aimed at extending Scrum for large-scale agile projects, while retaining Scrum’s object-oriented architecture. Scrum at Scale framework, along with its pattern library, are aimed at allowing agile projects to develop their own unique and customized methods for scaling Scrum to large-scale projects. In part 4 of this blog series, I will explain salient aspects of Scrum at Scale, and how its object-oriented approach may be used for customizing SAFe for your own unique needs.
Agile Scaling Aspects and Parameters: Any large-scale agile project needs to consider a number of scaling parameters in order to decide which scaling framework would be most appropriate for its unique needs, or whether it needs a totally custom set of agile processes. Table 1-4 shows a set of 25 scaling parameters, grouped into 6 scaling aspects:
3. Agile Methods and Environments
6. Value Chain
The list is a fairly comprehensive, but by no means, exhaustive. If some of the 25 parameters are not appropriate for your large-scale agile project, you need not consider those parameters. If any scaling aspect or parameter is missing from the list, please let me know. Each scaling parameter may take one more values from range of options. For example, “Number of teams” parameter associated with “Teams” scaling aspect has a value in the range of 10 to 1,000. “Composition of teams” parameter associated with “Teams” scaling aspect can select a value in its range of options: Developer-Centric, Somewhat Cross-Functional with Guest Experts, or Fully Cross-Functional. Multiple options can also be selected as long as they are not contradictory. For “Composition of teams” parameter, only 1 out of 3 possible values can be selected. On the other hand, for “Agile method of choice and required tool support” scaling parameter of “Agile Methods and Environment” scaling aspect (see Table 2), multiple choices are possible, such as Scrum, Scrumban, and Scrum+Lean.
Many of 25 scaling parameters are considered by ASK, DAD and Scrum at Scale frameworks. Tables 1-4 use the following legend to indicate which scaling parameter is covered by ASK, DAD or Scrum at Scale.
- A: ASK
- S: Scrum at Scale
- D: DAD/Agility at Scale
Note that some of the 25 scaling parameters are not covered by any of these frameworks. For example, “# 5. Composition of Teams: Fully Cross-Functional” scaling parameter is covered by all A (ASK), S (Scrum at Scale) and D (DAD); while “# 5. Composition of Teams: Developer-Centric” scaling parameter is not covered by ASK, Scrum at Scale or DAD.
As you review the information in Tables 1-4, you will realize that the “scaling agile” space is complex and very rich with many choices. Each organization or a large-scale project is likely to select a different combination of these scaling parameters as relevant; moreover, the value or range of values for each scaling parameter for a project or an organization is likely to be unique.
What agile-lean scaling approach are you considering: SAFe, LeSS, DAD, MAXOS, or something else? What are your customization needs, and does your selected approach fit well with those needs? I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com). I’m also on Twitter@smthatte.
Stay tuned for these future parts of this 4-part blog series:
Part 2: Scaling Agile Your Way – SAFe vs. MAXOS
Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS
Part 4:Scaling Agile Your Way – How to develop and implement your custom approach
What’s your lucky number? In June, I attended the Agile West BSC/ADC conference in Las Vegas and didn’t do so well at the roulette table; however, two months later on 7/21/14 (lucky 7s) I placed an even bigger bet; not on red, but on Pantone Color Number 216. It’s the signature color of VersionOne, the all-in-one agile project management tool and services provider.
After almost seven years of building up my agile acumen at Cars.com, I decided that it was time to close that season of my career, and I began researching and planning my next career challenge. I outlined three key pillars that were very important to me and my ability to truly enjoy going to work every day:
- Customer Centric Vision – Having the ability to know WHY what we do matters to customers, and matching values and alignment to priorities.
- Clear Agile Direction – Finding a company who is moving the agile ball further down the line.
- Fun and Innovative Culture – Life is too short and if you are going to work hard, it makes it much easier to find the joy in your job if you have fun doing it.
These were the most important traits I was seeking in part because they were the things that made me love being at Cars.com. I plugged into my network, had some interviews (and one offer that didn’t work out), and continued my quest to not settle until I found a career that valued these same traits. Then, just when I thought that finding my career “Match.com” was out of reach, I found an opening for a Chicago-based Product Specialist that turned out to be the perfect blend of vision, direction and fun.
Luckily for me, it was also at a place I knew very well, VersionOne. After a few interviews and a relatively painless courtship, I accepted the position and can report that so far it has been a jackpot payoff.
Since my start at VersionOne, I have validated or learned seven key things that I believe you can also learn from, no matter where you work:
- The customer is king (or queen); however, not everyone is a customer – If the slipper doesn’t fit, you can’t force it!
- Community is very important – Sometimes a company does things because it’s for the greater good.
- You can’t fake culture – If you’ve got a great culture, you’ve got it. Hang onto it.
- Agile is a mindset, not a methodology – Like culture, the question is not “Are you Agile?” but rather, “How Agile are you?” If you aren’t sure, take this Agile Development Quiz.
- Cold beer, anyone? A cold beverage and a game of pool after work is still a great way to end the day. When they say “Work Hard, Play Hard,” believe them!
- Valuable training is essential – Among the many other benefits, new-hire training as a group bonds people together and to the company.
- VersionOne is a great place to be because of the people, agile project management products and services to help companies achieve agile success, as well as VersionOne’s commitment to the agile community at large.
Going into my Product Specialist position I tried hard to find red flags, indicators that would give me some warning or reason to pause. At the end of the day, every flag I saw was Pantone 216. It’s my new lucky number!
I hope you find your lucky number, whether it’s a career at VersionOne, a business engagement with us, or something totally unrelated!
Read more on my personal blog at a12p.blogspot.com.
Today’s fast-moving markets expose threats and opportunities at every turn. Whether you’re a large enterprise or a small startup, it’s no longer enough to simply practice Agile development. To survive — and thrive — in this disruptive environment, you need agility throughout your organization.
Join Rally and Chef for a webinar about the role of DevOps in building agility and responsiveness. Learn more about how Rally practices continuous deployment, accelerates application development, and tightens customer feedback loops. Hear how you can institutionalize DevOps and use Chef to support a speed-focused approach.
DATE: Thursday, September 4
TIME: 11:00 AM Pacific / 2:00 PM Eastern
- Jonathan Chauncey, developer at Rally Software
- Jeff Smith, development manager at Rally Software
- Colin Campbell, director of patterns and practices at Chef
- [moderator] Alan Shimel, editor-in-chief, DevOps.com
Register here: http://devops.megameeting.com/registration/?id=1949-232488Rally Software