3 Tips to Becoming Agile@Home

Agile Principles Easily Transfer to Family Life

The COVID-19 pandemic has forced us to pivot and stretch more than we ever imagined. Agile is well known in the software development community. This way of working can also be embraced and adapted to other environments. Learn how I leveraged the The Agile Manifesto to be Agile@Home.

The Agile Manifesto has 4 Values supported by 12 Principles that guide teams who develop software, solutions and services. When you take a few minutes to really think about it, many of these values and principles are easily transferrable to non-software development teams.

For example, consider these Agile Principles:

  • #4 Business people and developers must work together daily throughout the project.
  • #12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • #3 Responding to change over following a plan.

In our homes, we also strive to work together, take time to reflect on our growth as a family, and to adapt when our plans are disrupted.

None of us started the calendar year thinking we’d be battling a global pandemic. As we all scrambled to create new routines, I began to slowly introduce my family to the values described in the Agile Manifesto. I shared practices and tools with my family that I would typically only use with the leaders and teams I coach.

I started to notice positive change. I observed more independent learning and accountability for schoolwork as well as general household responsibilities (chores). My family survived the spring and summer. After learning the beginning of the 2020-2021 school year would be a continuation of virtual learning, I realized Agile@Home would become a way of life.

Most of us do a fairly decent job with visualizing our work at home. We create To Do lists, Kanban boards, spreadsheets and shared calendars. Given that assumption, I’ll share with you 3 tips that go beyond the basics to make your home more agile. You can be Agile@Home by:

  1. Implementing Timeboxes
  2. Building Buy-In
  3. Enhancing Communication

1. Implementing Timeboxes—What is a Timebox and Why is It Needed?

Timeboxes give us limits to working on a defined task. They are important to build awareness and establish boundaries as needed. In our homes, these timeboxes may look like a bedtime/wake-up routine, a scheduled exercise/gym time, cafeteria availability, office hours, online class time or even tech time (i.e., video games, TV, cell phone usage). These timeboxes can be negotiated, but will only be proven effective with buy-in and compliance.

2. Build Buy-In—Why and Who Participates?

Change is proven to be most effective when all parties involved have a seat at the table. Instead of the boardroom table, the entire Agile@Home team should meet at the kitchen table (or their favorite comfy spot) to create a sustainable work-life agreement. Agile teams create agreements to outline expectations for how they’ll operate and self-organize. The Agile@Home agreement should do the absolute same! Buy-in boosts individual accountability. This in return helps to increase trust through inclusion.

3. Enhance Communication—Family Feedback

An agile team is coached to integrate feedback loops into their way of working. Example feedback loops are Retrospectives in Agile and Lessons Learned in Traditional Project Management. Agile Retrospectives occur at an agreed upon frequency, day and time to ensure the entire team is available.

With Agile@Home, this is a forum of sharing. Everyone has an opportunity to share what’s been going well, what’s not going so well, and what processes should continue.  This time should be used to celebrate each other’s accomplishments. At home, this could be in the form of sharing promotions, good grades or new skills learned. Other feedback loops can include daily stand-ups, a family meeting or a demo of completed projects/school work.

Each household is unique, so you will need to determine what timeboxes, agreements and feedback loops make the most sense for you. Remember to start by defining expected outcomes and objectives. After you have figured that out, don’t forget to inspect and adapt.

What actions will you take to be more Agile@Home?

Love this post? Then subscribe to our mailing list!

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


Tremillia H Williams headshot


Tremillia Highsmith Williams, Co-Founder of MiLu Unlimited LLC
email: milu.unlimited@gmail.com
website: www.miluunlimitedllc.com
LinkedIn: https://www.linkedin.com/in/tremillia-highsmith-williams-0050842/




Wanted – Guest Bloggers Passionate About Agile

read more

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

Release that MVP ASAP

Releasing that Minimum Viable Product (MVP) is More Important than Ever Before

When I teach agile planning, I emphasize the importance of defining the Minimum Viable Product (MVP) and its influences on the product development lifecycle. Eric Ries best explained how to apply the MVP concept to entrepreneurship in his renowned book The Lean Startup. His definition of the MVP is “that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.”

I’m usually hired to consult with clients long after the time to release the MVP has passed. Often, I find myself looking at a poorly designed product with a convoluted user experience. 

I recently worked with a client developing a SaaS product without a well-defined MVP. They churned back-and-forth on design requirements for months to produce a product with a confusing user experience. Because they missed too many MVP deadlines, they decided to call their first release Alpha instead. Sound familiar?

Report Pre-Launch Cost of Redesign to Investors?

Many executives, like my client, find themselves running out of development budget runway and desperate to get their product to market. Even if my client’s product launch is successful, this negative impact to corporate solvency could easily have been avoided.  

If more businesses had to report to their investors dollars lost due to pre-launch rework and redesign, the MVP would be treated with higher priority. In today’s competitive landscape, businesses must get their products into the hands of potential customers faster than ever before. This suggests businesses who continue to haphazardly develop new products have even less chance of survival.  

Most have heard some rendition of the quote: “Fall in love with your customers, not your product.” You read this and nod your head. Yet, somehow many who develop new software products tend to fall in love with the technology first and assume their chosen customers will fall in love with their vision for it too. Technology may be cool, but people pay for transformation. Your product must solve a real or perceived problem, and it must be easy to use.

Why is the MVP so Important?

The MVP process is crucial to identifying what features to release first. Without feedback about whether or not the product developed satisfies customer needs, it’s anyone’s guess whether or not people will purchase the product and recommend it to others.   

The good news is that agile Epics and Stories already focus on the customer viewpoint and experience. 

How Do You Define an MVP and Build a Better Product Backlog?

Stop thinking you are the customer and start looking at your product from the viewpoint of actual customers who need to solve a problem.

Learn about the problem from the customer perspective:

  • What problem(s) do your customers need to solve? 
  • When would customers access your application? At what point in the resolution process?
  • Why do current products miss the mark? 
  • How do customers expect the application to work? 

Define a user experience that makes it quick and easy for the customer to accomplish their goal. The MVP proves the concept; it is not the end product. The most technologically cool method may not get you to market quickly enough. 

Design an MVP that Leads to Continuous Improvements

Organize the MVP features in such a way that the new product can hold its own in the marketplace. The MVP must be a quality product that can stand up to the competition. It must look complete, even if it only includes a fraction of what you plan to include down the road.

  • Design a way to get customer feedback as quickly as possible. 
  • Test your assumptions. 
  • Enhance what works. Pivot when necessary.
  • Release improvements along with new features.

I’d love to hear stories about how your teams have successfully implemented an MVP. Do share!

Love this post? Then subscribe to our mailing list!

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


Cynthia Kahn

Cynthia Kahn


Cynthia Kahn

read more

Practical Agile over Ideological Agile

When is it OK for Practical Agile to Overrule The Scrum Guide?

In these fast-paced, often unpredictable times, should we change our approach to training and teach more practical agile methods, so our clients are better equipped to manage change? I’ve been reaching out to colleagues and competitors, discussing the state of agile training and consultation. Many of my colleagues still believe that certification in their favorite ideology is the best approach to training.

Certification Teaches Ideology

Certification trainers teach the rules and ideology of their method du jour, mainly The Scrum Guide, Disciplined Agile Toolkit, Scaled Agile Framework or favorite ICAgile topic. Each method has their own idea of what it means to practice agile. That implies there is no one right way to practice. I acknowledge that many students take certification classes to beef up their resume. With high unemployment rates, everyone wants their resume to stand out. 

Good certification trainers reach into their own on-the-job experience to explain how they’ve applied the principles to past projects. However, not all certification trainers have actually worked as scrum masters or product owners on an agile team. Their students learn enough ideology to pass an exam. The reality is that some students may return to work after passing their certification exam unprepared for the challenges ahead.

Practical Agile Increases Adoption of Agile Mindset

I love Scrum and the agile mindset. I am a practicing Certified Scrum Master (CSM) through the Scrum Alliance, I teach practical agile methods based on Scrum, and I spent the last year developing a program for individuals to apply practical agile methods to their personal lives. Our company, GSD Mindset, prides itself on teaching, coaching and practicing our practical agile approach called the GSD Scrum Method

World and business leaders must adopt an agile mindset or their organizations may not survive, given we live in a world with many unknowns. To increase adoption of the agile mindset and therefore increase our client’s chances to succeed, we should add a 13th Practical Agile Principle to the original 12 Agile Principles: Take a practical agile approach over our ideology as written.

Ways to Make Scrum Practical

Since we teach an extension of Scrum, I’ll use Scrum to illustrate my point. Many organizations adopt their own version of Scrum anyway. Sometimes those organizations see productivity and quality improvements, sometimes they don’t. Because we are agile influencers, it is our responsibility to guide the individuals who take our classes to apply a practical agile approach that actually works for their business.

For example, The Scrum Guide assumes you already have a prioritized Backlog. Many who practice Scrum don’t know how to organize and build one. Even though building your first Backlog is not in The Scrum Guide, our primary responsibility should be to provide our clients with tools to start focusing on the right things in a more productive way, and that starts with building a well-written Backlog:

  • How do you decide what to build?
  • How do you define the Minimum Viable Product?
  • How do you prioritize a Backlog? 

Even the authors of The Scrum Guide admit that Scrum is “Difficult to Master.” As coaches and trainers, after we train our clients how to build a Backlog, we need to help them correctly adapt the formal Events of Scrum to work in their unique situations:

  1. Plan without knowing all the answers.
  2. Meet Daily to keep focused on the right things.
  3. Review status and quality of work on a regular basis.
  4. Reflect on what’s working, brainstorm new ideas and learn how to recognize when to pivot. 

The key is to internalize the ideological principles and develop a practical agile approach that you can adapt to any situation.

Are you certified?
How have you changed your approach to agile?
Do share! 

Cynthia Kahn

Cynthia Kahn


Cynthia Kahn







Wanted – Guest Bloggers Passionate About Agile

read more