Recursion: An Agile Approach to Business Change

Apply Recursion Concepts to Agile Transformation

How does the computer science concept of recursion tie into an agile business transformation? Recursion reduces the complexity of change, so teams evolve at a speed that is balanced with their abilities and offers the best chance for success.

When a business initiates an agile transformation, the task can seem daunting. There are so many areas which may need improvements and where an agile framework needs to be applied. It may be hard to identify and prioritize the improvements.

By human nature, many teams will be resistant to change. For these types of reasons, it’s a good idea to break down the transformation into smaller, incremental steps. On the way to becoming agile, take an agile approach to determine where to focus the incremental changes: Recursion!

Agile uses an empirical model in an iterative process. An understanding of how things are working in the business needs to be realized in an open and transparent manner. This understanding needs to be inspected and analyzed. From this, an informed decision is made to adapt the business.

What is Recursion?

In the analog world, an example of using recursion involves a game with three wooden pegs. Some number of disks of increasing size are stacked on one peg, with the largest disk on the bottom of the stack. The purpose of the game is to move all the stacked disks from the initial peg to another peg. By the rules, you can only move one disk at a time, and you can never place a larger disk onto a disk of smaller size.

In computer science, a recursive function is a coded algorithm that calls itself. The computer science recursive concept solves the analog puzzle digitally by breaking down the movements into smaller subsets of actions. These actions are then executed with the same bit of code, simply the function to move a disk following the rules, building upon one another repetitively to complete the puzzle. A typical example which is used in a Computer Science 101 course involves the Tower of Hanoi.

This example of recursion helps to represent the idea of using a concept to lead to and from the same concept. In other words, the same concept is used within the larger version of the concept. It’s a brilliant and efficient way to code these types of jobs. Once this first step is completed, it is repeated, building upon itself.

Determine Where to Adapt

Initially, you may want to focus on adapting a process that is the least complex, as there may be best methods and guidelines that can be quickly adopted and implemented. Always consider the value the changes bring to the business.

With each iteration, you always need to consider the vision for the business with an understanding of the business processes. With this transparency, you can begin to break down what changes might be implemented. Make sure all the teams understand the vision and values of the changes. Engage with employees for an open and respectful discussion, working together with mutual purpose.

The recursive approach allows you to take small steps in an efficient and transparent manner, gradually applying improvements. Employee engagement with the advancements help guarantee the changes are lasting. Once a change is implemented, step back and look at the impact on the business, and then start the same process again.

Look at the data, analyze and make choices, and adapt. An agile coach can provide guidance and an understanding of where you may want to focus, and how to make changes with best practices.

Agile is not the Towers of Hanoi

Although the Towers of Hanoi nicely expresses the idea of recursion, it implies that at some point the job will be done. That is, all the disks will be moved from one peg to another. However, in applying agile, the business never comes to a state where we can say, “Our work is complete!”

Agile is a mindset and an expanding journey. Continual improvement is ever present in agile and is especially relevant in today’s modern digitized market and workplace where constant change is forced upon businesses at multiple levels.

With the idea of recursion and repetition behind your agile journey, you can reduce the complexity of the changes and see improvements evolve at a speed that is balanced with your employees and abilities, and with the best value for your business and the customer.

Love this post? Then subscribe to our mailing list!

We guarantee 100% privacy. Your data will not be shared.

 

Erik Major

Erik Major

 

Erik Major is a Product Owner, Systems Engineer, and Agile Advocate with a background in computer science, telecommunications, and SDLC.
Contact: erik.j.major@gmail.com
LinkedIn: https://www.linkedin.com/in/erik-major/

read more

MVP for Major IT Transformation Programs

IT Transformation Leaders Should Deliver MVP First

IT leaders love to announce the launch and deployment of large transformation programs. Such announcements motivate the entire organization with the prospect of exciting and challenging work ahead. Seasoned leaders know that transformation programs usually span multiple years. So, it is best to pilot with a Minimum Viable Product (MVP) of limited functionality for a small customer base. Then, follow the MVP with enhancement releases and additional onboarding.

Building the MVP first is common practice among IT leaders when a single product needs to be developed. For some reason, the MVP practice has not been widely accepted for major IT transformation programs. That may be why some IT leaders mistakenly decide to go with a Big Bang deployment, foregoing the MVP.

For example, take a large IT transformation initiative that must be complete by the end of the fiscal year. By year-end, multiple products must work in tandem and satisfy all the business requirements for the entire customer base. Leadership decides to take the Big Bang approach stating that the organization must be prepared to take on additional initiatives in the next fiscal year. A date is set.

Development teams are told that the solution must be ready by deployment date, despite concerns raised by the rank-and-file about the level of effort involved. Buggy code, frustrated engineers and dissatisfied customers wanting to go back to their legacy solutions are all too familiar results. Early decisions made during planning are not revisited for a range of reasons.

What Happens When the IT Transformation Fails to Deliver?

Regardless our promises to learn from similar mistakes made in the past, leadership continues to make the same mistakes over and over again. Listening stops at a certain level of management in a hierarchical organization. No one wants to raise concerns up the management chain or across to their peers for the fear of losing credibility or brand.

Some IT leaders may not participate in planning and commitment conversations with their business peers. They blame the rank-and-file for failure.

Are you surprised that such failures recur despite having robust Risk and Issues Management processes in place?

Traditional Waterfall Approach is Not the Root Cause

Some readers will immediately say, “This is what you get when an organization uses old-fashioned Waterfall processes.” I believe that the root cause of such failures cannot be blamed squarely on the use of Waterfall approaches for program planning and management.

The lack of MVP could be the cause. Why not implement a process or two end-to-end for the initial launch? Or why not pick two of the most important products in the solution, configure their functionality and integrate them?

Prioritize Processes and Implement High-Priority Processes First

Instead of trying to prioritize the whole stack of business requirements, prioritize processes within the new solution with the understanding that the legacy applications live in parallel until the rest of the processes are fully migrated. Agile teams understand that breaking down large-effort user stories into smaller manageable ones for faster and easier implementation is a learned skill.

Failure is Not an Option

Some may argue that the pressure to deploy with a Big Bang approach may be due to uncertainty regarding funding for the next fiscal year. My counter-argument is the risk of major failure with Big Bang approaches. It is better to start by deploying something small that is usable.

Consider adding business value early in the transformation lifecycle over delivering nothing at all. If investment dollars are going to be difficult to secure next year, the program can be paused until the situation improves.

This is about listening to one’s gut and promoting open communication between people at all levels in an organization.

Love this post? Then subscribe to our mailing list!

We guarantee 100% privacy. Your data will not be shared.

 

Anil Bhat

Anil Bhat

 

Anil Bhat is a technology professional with twenty-plus years of experience in software development, analytics and product leadership.

 

 

 

 

 

 

Wanted – Guest Bloggers Passionate About Agile

read more

Help Your Team Overcome Past Scrum Failures

4 Ways to Overcome Past Scrum Failures

When it comes time to begin their Scrum journey, many teams come with baggage. I often hear, “We tried that, and it didn’t work.”  They may have “tried” Scrum before and “it didn’t work.” They may feel Scrum is yet another management fad.

Like unhappy families, team members may come from other teams that failed for different reasons. Here are some ideas a Scrum Master can use to help their new team overcome past Scrum failures. Through positive experience, help your team give Scrum another, successful try:

  1. Lead with empathy. Listen to your team. Learn what didn’t work before and what they most need now. Try to help them address the problem applying Scrum methods. You may have diagnosed different issues with a Scrum lens, but that can wait.
  2. Lean into exceptionalism. The things holding your team back aren’t unique, but who wants to be told that?  Accept and work into their excuses.  You can also build credibility by championing adjustments that use more common sense and are less rule focused.
  3. Celebrate transparency before results. High achieving individuals are accustomed to striving for the great report card.  Your job as Scrum Master is to decouple that dopamine hit from story points and attach it to the act of finding the baseline and ownership.
  4. Stick with basic principles. Scrum done well has any number of tools, and a Scrum Master should be aware of all of them.  With a new or resistant team, focus on the key few that suit your style.  For me, that is keeping Daily Standup short and effective, holding a regular Retrospective, and striving for predictable delivery.  Other things, even scrumly rituals like sizing, may fall away.  The team will discover them anew as they build trust.

I started working with one of my favorite Scrum teams six months ago. They were reluctant to try Scrum because it had been presented as an all or nothing scheme that would add overhead to existing business processes. Some had been burned by personal experience.

At our Director’s urging, they agreed to try Scrum but admonished me to keep it lightweight. Two weeks later, a reorganization placed them under new management, reducing higher level support for Scrum. The team was at a project phase with high scrutiny where work was driven by urgent issues.  The engineers were experts assigned to specific areas and rarely worked across those boundaries. It was an inauspicious time to demonstrate the value of Scrum. Luckily, the front-line manager decided to give it a try anyway.

I charged in with the religious zeal of a Certified Scrum Master confident of winning more converts. After three months, the team remained highly siloed. The Accept/Commit Ratio hovered around 50%. Overall velocity was stubbornly flat. I expected to see the experiment called off.

However, the team understood what they were up against.  They helped me coach them.  I learned about their challenges with deadlines and validation requirements, and about the mix of skills in the team (empathy). Their company-mandated ticket system was poorly adapted to Scrum. Rather than do data entry in another system, they found a way to make it work, and I built a manual dashboard (exceptionalism).  We focused on seeing and improving the trend in our improvised Scrum board through anecdotes of improved focus and collaboration (transparency).  I kept my promise to keep it lightweight and they readily bought into having regular Daily Standups and Retrospectives (basic principles).

Over time, they developed improvements in tracking on their homemade system and in Backlog Grooming. They found ways to share work fairly across projects.  They engaged their validation team and internal customers as a part of the Scrum process.

After more than a dozen Sprints, the team has hit a groove.  Their Accept/Commit Ratio approaches 90%, and they are developing a discipline to baseline and address their interrupt rate.  What’s more, they have maintained their Scrum practice while rapidly adjusting to working virtually in a coronavirus world.  They are now a team that says, “It works for us.”

Emily Hackett

Emily Hackett

Emily Hackett
https://www.linkedin.com/in/mlehackett/

Emily is a Technical Program Manager working with the Performance Architecture and Analysis team at Intel.  She has been a Scrum Master since 2016 and has also worked as a Release Train Engineer (RTE) in a Scaled Agile Framework (SAFe) organization and as a functional manager for a highly effective Scrum team. Opinions presented are her own.

 

 

Wanted – Guest Bloggers Passionate About Agile

 

 

read more

Part 2: Does Perfect Scrum Practice Make Perfect?

3 Reasons Why My Perfect Scrum Teams cannot Make Perfect

Wow! It’s been 9 months since I’ve written a blog post. A lot has happened since I wrote Part 1: Sometimes Change is Really, Really Hard. I’m still at the same client, finishing up a year of agile consulting. Let me fill you in on what’s been happening there.

Before I get started, I’m excited to tell you about what else has been happening since my last post. Last November, I gave a TEDx talk that explains how to Apply Agile Practices in your Life and be Happier. I share my backstory and describe how agile transformed not only my business life but my personal life too.

That TEDx talk was so well received that immediately afterwards, Gerri and I started to develop a 12-week guided workshop that can help anyone achieve their goals through applying agile principles. If you’re interested in learning more about our upcoming FREE goal setting workshop, contact us and we’ll put you on our brand new email list.

Now, back to my agile consulting client.

Part 1 Challenge Update

When I wrote Part 1, my biggest client challenges were:

  • Teams organized without a permanent Product Owner.
  • Project Management Office (PMO) tracking methods at odds with agile methods
  • Poor Release Management practices.

In the last 9 months, I’ve made good progress in these areas.

I was able to influence team organization through my relationship with the PMO. I helped management see the confusion caused by conflicting priorities when Product Owners are assigned to projects and not teams. I’m happy to say that now my scrum teams have a permanent Product Owner to prioritize project requests coming into the team from across the globe.

I locally fixed the tracking methods issue. The PMO still sizes and monitors progress in Dev Days, but now all the scrum teams at our local office have switched to relative story size techniques. After all the stories are sized, I roll up the story points and calculate Dev Days for the PMO. My teams receive the benefits of relative sizing and the PMO gets what it needs for management reports. Win-Win.

Release management is outside my local sphere of influence. Although I could not change the poor release management practices, I report time lost due to these issues in every sprint status report. This way, I quantify the impact to upper management every 2 weeks. Hopefully, someday upper management will see the light.

Perfect Scrum Practice Doesn’t Fix Everything?

Now, we practice scrum the best way possible. We plan Projects, we write Stories, we groom Stories, we plan Sprints, we Standup, we Demo and we reflect through Retrospective. Then why, why, why are my teams not perfect? Because at the end of the day, we’re building software, and we must follow best software development practices too.

Top 3 Reasons Why My Teams Are Still Not Perfect

The top 3 software development practices that prevent my teams from realizing all the gains from perfect scrum practice:

  1. Skip analysis and design as part of Definition of Done (DoD).
  2. Minimal or no unit testing by developers before passing story to testers for verification.
  3. Maintain unstable Develop and Test (Pre-Production) environments.

In traditional waterfall software development, the entire project goes through a systems development lifecycle (SDLC). One phase in the cycle must be completed for all the requirements before continuing to the next phase.

With scrum and other agile frameworks, every story (or small set of requirements) should go through the same SDLC as an entire waterfall project. Agile does not equate to lack of design. In fact, design is even more important with agile projects, which are built story by story. Without a solid design, the team runs the risk of incrementally developing software that does not fit together correctly at the end. Poor design or lack of design also increases risk of technical debt.

When developers don’t take unit testing seriously, the quality of code passed to the testers for verification is low. The initial builds do not produce code that works the first time. Stories go back-and-forth between develop and test. Stories take longer to close. Maybe the team just likes the drama?

Shared test boxes are wholly maintained by the developers and testers instead of Operations. This causes a litany of issues for version control, upgrades and releases. Issues multiply when multiple changes deploy from multiple teams working on multiple projects in multiple countries. Environments break. Many hours, even days, are lost.

Introduce Changes in Software Practice at Retrospective

At every Retrospective, I recommend appropriate changes when problems are discussed that I believe stem from the lack of best software development practices. Every time. Even if crucial practices are not adopted, I continue to teach until my team is ready to learn.

Environment issues cannot directly be be fixed through internal team process improvements, However, Retrospective provides an excellent opportunity to discuss different ways to approach and work with management. Teams can have powerful influence when they manage up.

As consultants, we always hope we can bring our clients from darkness into the light.
I guess that’s not always possible, even with the best intentions. However, continue to make constructive suggestions and find ways to track then report the impact. Telling a consistent story ensures that when teams are ready, they will hear you and take action.

If you have any techniques that you’ve applied in your own practice that could help, please share,

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru
503.799.5500

read more

Part 1: Sometimes Change is Really, Really Hard

Or Can This Client be Saved?

I know that I haven’t blogged for a while. My move from Portland, OR to Austin, TX was a big change for me and it took more energy than I anticipated. I’m finally settled and working on a new contract. My current client moved to scrum without training or fully understanding the agile method. Therefore, they transitioned themselves into a bigger problem than any I’ve had in my move half way across the country.

We like to think that businesses hire consultants at the beginning of their agile transition, to ensure everyone understands how to practice scrum and to reinforce the shift to an agile mindset. But, we know that many businesses just start practicing what they call agile or scrum, and they don’t hire consultants until some aspect of their process is so painful they must change or face even more declines in productivity.

I am usually up to the challenge. I’ve been practicing agile scrum for over 10 years now, and I’ve seen many forms of practice. However, in my new back yard, I find myself in the middle of the biggest mess that I’ve faced in my decade long career.

As change agents, we hope to be brought in at the highest levels of the organization, so we can lead with the support of upper management. However, in reality, we are brought in as scrum masters or coaches, working at the team level without access to upper management. Until now, this has not been much of an issue. Scrum is a team sport right?

Right…but…scrum is an application development method. I’ve written many times about how product management, project and program management, and even release management are Forces outside the team. Yet, these Forces impact the team’s ability to practice scrum in the manner necessary to predictably get stuff done and allow them to leave work by 5 pm and not work evenings and weekends.

The Force is not conspiring to ensure my teams can successfully practice scrum.

Here’s my challenge:

  • We don’t have the right team organization. In this case, the Product Owner is not at the right level of authority.
  • The Project Management Office (PMO) processes are at odds with agile methods: project sizing in Dev Days, story sizing in Story Points (maybe) and tracking task work in Hours.
  • Release Management is chaos. Releasing code to Production after acceptance is so time consuming that velocity is drastically impacted.

It’s easy to recognize the root cause of problems and offer suggestions. It’s not so easy to influence upward and convince senior management that the pain of change is less painful than their current situation where almost every project is yellow or red, with unpredictable delivery and disappointed customers.

Is the problem too big for me to solve from the lowly level of scrum master for 2 scrum teams in Austin while working for a major international company? Maybe. We’ll see.

I heard many times that we aren’t given challenges we can’t handle. So for now, I accept.

I continue to train and encourage my own scrum teams to correctly practice scrum in a way that allows them to be successful in this crazy environment. I am helping them learn how to write better stories, size in story points, use their voice to accept or not to accept a story for sizing or into the sprint backlog, and to time box. Our goal is determine a realistic sprint velocity.

I work with the local Engineering Manager and the PMO Director to outline symptoms, root cause and potential solutions to problems. This is the first step to influencing upward.

I have offered to train as many teams as possible in the GSD Scrum Method, our real world application of scrum. None of the teams have received formal training or coaching.

This is my first in a series of posts outlining my journey.

Hopefully, it’s not too late and I am truly up to the task.

I appreciate any and all suggestions.

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru
503.799.5500

read more