First for the background on Agile Practice.  In February 2001 (while I was finishing my undergrad at Ball State University), 17 people got together at a ski lodge in Utah to “talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto.”  

Fast forward a few years, and it was sometime in 2007.  Where I was working at the time, we had a Lean Six Sigma Black Belt.  She encouraged me to look into this whole “Agile thing.” So the first book I stumbled across was by Mike Cohn – Agile Estimating and Planning.  The overarching concepts about how to plan and estimate work into manageable chunks, then execute just made sense to me.    

So over the next two to three years, I consumed as much information about Agile practice as I could.  But more importantly (unbeknownst to my team at the time) I constantly tried the different techniques I was reading about.  My main goal was to put my learning into practice, the concept of “shu.”

The philosophy of Shu-Ha-Ri within Agile practice was first introduced to me by Alistair Cockburn while reading his book “Agile Software Development.” After reading his book I was also fortunate enough to see him speak at the Agile and Beyond Conference in 2015 on this very topic.

Now I am over ten years into my Agile journey. While I feel as though I have moved to the “Ha” level (future posts coming on that), but I am still learning each day. So to get us started let’s dive into the traditional wisdom or values that define Agile, and I will share some thoughts or experiences on each.

Individuals and interactions over processes and tools

It can seem strange that a concept rising from the software development world speaks to people interacting, rather than simply following a process.  Let’s face it, by and large software teams are typically introverted or seen as “shy.” So how does a concept which hinges on these introverted people being social actually work?

In my experience I have observed first hand that taking the time to get to know the development team personally begins to open them up to conversations.  All to often, their quietness is observed as “disengaged.” However, it can simply be an individual actively listening and learning prior to offering suggestions.  Allowing for the individuals to be themselves and slowly encouraging the interactions between the team creates a space where collisions occur. Teams are then capable of pushing the boundaries of creativity and innovation.        

Sure, processes and tools can keep projects predictable.  But is that what we want? Or would we rather have end results that solve problems in the best ways possible?  If your organization values innovation over strict process, then a focus on individuals and interactions can create an environment capable of transformation.          

Working software over comprehensive documentation

If you are unsure where to start with Agile, there are many schools of thought.  Often you hear “setup daily stand ups.” While I think stand-ups can be a solid way to get started, where I have seen the light bulbs go off is when you create a feedback loop that showcases small wins early and often.

Sponsors and customers buy into what the development team is doing when they experience the project growth along with the team.  Creating detailed specs to then have a sponsor or customer sign off on, without understanding them, doesn’t move the team closer to the eventual goal.  In contrast. Having the end user interact with what is being developed as early and as often as possible will create a product that meets or even exceeds the needs when it is launched.  

Therefore when I am asked, “We want to use Agile methodologies, where do we start?”  My advice is simple. Create the ability to share progress with your end user, or customer, or sponsor on an every other week basis.  Or every three weeks. Or Monthly. Whatever the best cadence is for your work.

Let’s look at a quick example based in web facing software development.  Start by creating wireframes or design concepts early in the project. After you review these, mock up a screen or two.  After that incorporate the backend functionality. Working this way brings the decision makers along from the beginning. It also creates that feedback loop along the way, allowing for small adjustments.  

So the key is to not worry about having things perfect.  That is the entire point, they shouldn’t be. This is because it is too early to know how to best solve the need.  Really the key is to create a safe space for teams to showcase work and gather feedback. This allows for small shifts to be made as teams learn.

Customer collaboration over contract negotiations

Let’s take a project focusing on developing something that the end user really does not understand.  How do we expect the 50-100 page statement of work to be something that offers value to the customer.  To that same point, when you develop something that ends up not meeting their needs, do you really expect to take out that document and convince them that you followed the contract therefore they should be happy?

My hope is that you have started thinking, “well no, that is not a good experience.”  But to further illustrate my point think of two scenarios from the consulting world. Decide which will make more money in the long term.

Scenario A:  $100k project, everything is defined upfront, the dev team develops, it delivers on everything in the SOW to a T, but ultimately does not solve the end customers goal.  

Scenario B:  $50k project, starts by focusing on a small scope, which progressively solves all the customers immediate needs because they are collaborating every step along the way.  This early success results in another project. Then another. Then another…      

Sure, the quicker money is scenario A.  You get more revenue, and quicker. But, scenario A is likely more difficult to create long term lasting value.  Now, if we consider scenario B we have made less up front, but we have created a very happy customer. We have also built the foundation of a relationship.  Sure, the future revenues are unknown. But can we agree that they are likely greater than $100k over the life of working with this customer?

More importantly.  You have now created an advocate for your organization’s services.  Furthermore, folks in organizations talk to folks in other organizations.  This happy customer now brags to his network about the great work you did. Voila, your next project comes in, and the next, and so on.  Pretty soon, you have built a relationship with a wide range of clients and that initial $50k you “missed out on” has now grown over $200k-$300k in revenue.  See where I’m going with this?

Responding to change over following a plan

I have been a project manager on hundreds of projects over my career.  Some big, some small. Now if I were to venture a guess, I’d say 50-60 percent of these projects were traditional waterfall projects.  With these projects came gantt charts, ugh!

The sheer amount of time I have spent building a project plan, with dependencies, and ultimately inaccurate estimates is hard to think about.  And with all of these project plans, there is one thing which occurred each and every time. My initial plan fell apart when we learned of our first change!  

In contrast, when we look at the many flavors of agile nearly all of them utilize strategies of progressive elaboration.  We create clarity as we learn. We don’t expect to know everything upfront because we have not learned anything yet. So for the purposes of this conversation I am going to look at a Scrum.  

With Scrum we capture an idea when it is purposed, placing whatever we know at the time about it in a ‘story’ that sits in the backlog.  Then when we get to defined times in our project lifecycle – for instance sprint planning – we take that story and elaborate on it. We better define the description.  We ensure it is a SMART deliverable. That means it is Specific, Measurable, Attainable, Realistic, & Timely. We also give a quick, relative estimate for the work against the rest of the items in the backlog.  With our last focus on creating an understanding of what ‘done’ means for this story.

Now sure, this seems like a lot.  However, look at it this way. Would you rather do this to 5 or ten “requirements” at a time?  Or should we sit down as a group before we do any work, or learning, and define hundreds of requirements?  Chances are that if we take an approach of “eat the elephant one bite at a time” our team is able to identify the best way to work based off learnings along the way.          

A few common misconceptions of Agile    

Many of the detractors to the agile movement have a similar piece of feedback.  It goes something like, “how can there not be a plan.” Or “if we don’t have a contract, how do we know what is agreed to.”  In my conversations with these folks, the typical question I ask is, “have you read the last part of the manifesto?” Then I get a somewhat bewildered look.

If they were to really digest the last paragraph, it really wraps up the idea of Agility.  

“That is, while there is value in the items on the right, we value the items on the left more.”  

So yes, there is value in a plan, but maybe just something with the key milestones.  Of course we need a contract if it is a vendor to client relationship. However, get the big rocks defined and work out the rest through collaboration.

Secondly there are the 12 principles.  These are often overlooked. But I believe these are best used by teams who are already working in an Agile environment, but feel like some things are missing or not working.  In my experience the most common is the idea that:

“Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

I’ve had multiple teams who feel like they are pushing too hard, or not able to keep up.  When this happens I’ve had to have that tough conversation with the sponsors. I lay out that a reasonable pace that delivers on time and with quality doesn’t have to include long hours.  Initially teams may deliver a lot of work. But teams burnout and work completed actually goes down over the long run.

As for my last concept, which is maybe the most important.  Keep in mind that Agile is a mindset.  Agile is not a cure.  It is not a process. It is not magic.  Agile is a way of thinking. It is a way of organizing.  It allows teams to grow through learning and creates a safe environment to stumble, but ultimately leads to growth.     

In conclusion

I have been and will continue to be a huge proponent of Agile practices.  Even before I knew what it was called, or knew the concepts that group of 17 people defined.  Truthfully I was already executing its practice. Human nature tells us that focusing on learning and adjusting as we go will more times than not lead to success. Especially when compared against exhaustive definition up front.

My hope is that this was informative, and that you will come back to this blog for more articles in the future.  I’m excited to dive deep into some agile concepts (more “shu” elements) and share some of my experiences (some “ha” elements). In the meantime, if you have questions or requests for future topics.  Reach out via my website or leave some comments below.  

The post Agile Practice: The Core Principles with my two cents (shu) appeared first on The PF Group, LLC..

Adopting a more flexible and responsive approach to project management can help your team become more productive, adaptive, and efficient. Here is a step-by-step tutorial on implementing agile practices in your team:

1. Understand the Agile Manifesto – Before beginning to implement agile methodologies, it is important to understand the underlying principles and values of the Agile Manifesto. This will help you gain a solid foundation of what you are trying to achieve and the key benefits of an agile approach.

2. Define Your Objectives – What do you want to achieve with Agile? Identify the objectives you wish to achieve, like shorter release cycles, higher quality products, or better customer satisfaction.

3. Identify Your Processes – Identify your current processes and the ones you want to improve. This includes identifying the team’s skill sets regarding agile practices and the current processes being used.

4. Choose an Agile Framework – Agile frameworks like Scrum, Kanban, and Lean are all beneficial to follow and give you a ready-made structure for delivering projects. Choosing the most appropriate framework depends on your business, goals, team size and experience.

5. Form Agile Teams – Create cross-functional teams which are self-organizing and cross-functional. These teams, composed of small groups, should be flexible and autonomous enough to deliver complex solutions to real problems. Identify a Product Owner, Scrum Master and Agile Developers who will lead and drive the team to success.

6. Facilitate Daily Stand-up Meetings – Daily meetings are a cornerstone of Agile. In stand-up meetings, team members discuss their status, what has been accomplished, and what needs to be done next. These meetings are brief and should ideally last under 15 minutes.

7. Implement Sprint Planning and Reviews – “Sprints” are sprints dedicated to strictly focused time boxes for product delivery, which are set up to give a defined and outlined timeframe for delivery. Each sprint includes planning and a review session, during which team members discuss progress, evaluate deliverables and identify any roadblocks.

8. Monitor Progress – Monitoring progress towards reaching set goals is critical to success. Monitoring project schedules, budgets, and progress against stated goals is essential.

9. Evaluate and Continuously Improve – This is key to ensuring effectiveness. Regular retrospectives should be conducted to analyze what went well, what didn’t, and what could be improved. This feedback should be used to adjust and improve your agile processes. Your team should also prioritize and regularly assess the value of the work being done, making sure to deliver value to the customer continuously.

Here we have attempted to give a quick view of some ideas for adopting agile practices in project management to increase team productivity, adaptability, and efficiency. We hops this step-by-step tutorial helps in implementing agile practices for your team.

The post Boosting your team’s efficiency and adaptability through Agile practices appeared first on The PF Group, LLC..

Agile Project Management (APM) is an iterative approach to managing projects that emphasizes collaboration, flexibility, and customer satisfaction. The principles of APM were first articulated in the Agile Manifesto, a document created by a group of software developers in 2001, but APM has since been adopted by a wide range of industries and organizations.

At its core, APM emphasizes responding to change, rather than merely following a plan. Instead of laying out a comprehensive plan at the beginning of a project, APM teams break their work into smaller, more manageable sections called sprints. These sprints typically last between one and four weeks and should result in a finished product that can be demonstrated to stakeholders.

Collaboration is also a key feature of APM. Teams work closely with customers and other stakeholders throughout the project, gathering feedback and adjusting course as needed. This helps to ensure that the final product meets the needs and expectations of the customer.

APM also emphasizes flexibility. Changes to requirements or priorities are welcomed, and teams are encouraged to make adjustments as necessary to meet customer needs. This allows projects to adapt to changing circumstances and stay on track to meet their goals.

To support this iterative, flexible approach, APM teams use a variety of tools and techniques. For example, daily stand-up meetings keep everyone informed about progress and help identify and resolve issues quickly. Retrospectives at the end of each sprint allow the team to reflect on what went well and what could be improved.

Overall, Agile Project Management offers a highly collaborative and flexible approach to managing projects that can be particularly useful for complex, rapidly-changing environments. By emphasizing communication, iteration, and customer satisfaction, APM teams can create high-quality products that meet the needs of their stakeholders.

Do you need help with your Agile initiatives? The PF Group is ready to help with anything you need.

The post An Introduction to Agile Project Management appeared first on The PF Group, LLC..

For context, my father Dr. Kenneth Rauch was approached about giving a keynote at a conference in Kota Kinabalu, Sabah, Malaysia. A former contact and her business partner had taken on this challenge by creating the Dare to Change: Construct your Future through Digital Transformation conference.

Soon after accepting the keynote, the idea turned toward bringing his son (that’s me) along to present a breakout session as well. This made sense given my 17+ year career in technology. So in the months leading to the conference, Dr. Rauch and I collaborated on all the ways my technology career and his organizational leadership career intersected and overlapped.

As the conference took shape, the organizers learned more and more about our collective backgrounds. As the planning heated up, they quickly turned toward the concept of Dr. Rauch and I presenting the entire two day conference. On top of that, I was asked to give the day 2 keynote on my favorite topic – AGILE PRACTICE!

The Content

During the two day conference, the delegates were presented with six key topics. Each of the topics attempted to build off each other, or complement a previous topic. Our attempt was also to make these sessions as interactive as possible, so we included exercises, videos, & continuous Q&A. For a full copy of the presentation, feel free to check out this link – CLICK HERE for the Prezi. But to kick things off, check out the intro video I created to open the conference.

Day 1

On the first day, we initially began with the foundation of what transformation truly means. This foundational topic allowed us to walk the delegates through an introductory understanding of how digital transformation can be enabled. Focusing on the human aspect was the primary emphasis.

After this introductory session, Dr. Rauch walked those in attendance through the topic of Cultural Intelligence (CQ). After describing CQ theory, a sample participative exercise was conducted. Upon completion of the exercise, we walked through an interactive analysis of how to interpret their individual results.

Our next journey was to dive deeper into the people side of transformation. Discussion focused on the idea that change is executed by people. We presented the concept that true innovation is achieved by finding the intersection between viability (business aspect), desirability (human aspect) & feasibility (technical aspect). Lastly we presented the concept of design thinking by showcasing the journey through empathize, define, ideate, prototype & test.

In our last session of the day, we walked through profiling the digital journey. In this session I was able to offer an introduction to Lean Startup concepts. Walking through the concept of creating a Minimally Viable Product (MVP) through validated learning. Also discussing how to utilize the build, measure, learn feedback loop model.

Day 2

To kickoff day 2, I took the stage to discuss my favorite topic – Using Agile as your Digital Culture. I began by walking the delegates through an exercise to gauge their organizational readiness to adopt agile practices. From there I gave a quick history lesson on the roots of Agile. Then to wrap up the introduction to agile concepts, I showcased (in detail) the use of the Scrum framework. Lastly to finish off this topic, I shared two examples of leveraging agile practices from my career.

During our second session of the day, we presented ways that digital transformation is occurring in education. We presented the concept of micro-credentialing, digital badging & showcased an example of Scrum being used at a secondary school in the Neatherlands – eduScrum.

Also in this session we dove back into how organizations need to think about moving toward agile practices. I presented the concept that Agile is not a process. Rather it is a shift in mindset. When you focus on delivering value, validated learning & transparency your organization is ready for an innovative culture to develop and thrive.

We wrapped the conference presentations with a brief recap of the concepts that had been presented in the last session of the two days. As we left the delegates we challenged them to consider… Are you the 21st century leader who will dare to change?

The Forum

To finish off the conference, Dr. Rauch and I participated in a five member forum comprised of local business leaders and government representatives. Our moderator Michael Dance (fourth from the left) took questions from the delegates and posed them to the forum. From there the forum provided feedback or experiences to those in attendance. This forum served as a fitting finally to the two day conference.

It was a great pleasure to share the stage with such accomplished individuals. We had a representative from MARii (second from left), Peter Stenberg Managing Director of Rustic Travel Group (second from the right) and Stella Matilda Editor for Parents Avenue (first from the right). Being able to understand their insight as they were fielding specific questions from delegates was amazing. They focused on real challenges faced by Malaysia businesses and it was an eye opening experience to finish off our two days.

The People & Culture

Given this was my first time traveling to Malaysia, I was not sure what to expect. Truth be told, I was blown away by the people I continued to meet. The hospitality from the conference organizers, meeting many of the delegates, and even making friends at the swim up bar all created wonderful experiences. I hope I have the good fortune to head back there someday in the future. This was a very special experience.

In Summary

This adventure was phenomenal from top to bottom. Being able to share this incredible opportunity with my father was very special. But more importantly being able to share our collective experiences with the people who gathered from all over Malaysia was spectacular. As I said, I hope to return someday on my future travels. Knowing how wonderful of a place Kota Kinabalu, Sabah, Malaysia is will make the long travel time that much easier!

The post Dare to Change Conference Re-cap appeared first on The PF Group, LLC..

The Dare to Change conference will focus on three key objectives.  

• Leveraging digital innovation effectively throughout the entire organization.  
• Increasing employee engagement and efficiency through improved customer journeys and loyalty.
• Enhancing internal collaboration and communications.

With an estimated 200-300 participants ranging from executives, business owners, & educators, attendees will learn both theory and experiential topics around:

• Digital Transformation – Transform or disappear
• Cultural intelligence introduction, exercise & analysis
• People first, setting a digital culture
• Profiling your digital journey
• Using Agile within your culture
• Digital transformation within education
• “Dare to Change” concepts to practice

Lastly, to finish the conference a six member panel will take questions and provide further insight into conference topics.  The panel will include a dais representing:

• Director of Ph. D program (Dr. Kenneth Rauch) – c
• Digital & Agile Consultant (Michael Rauch) – c
• CEO of MARii – c
• Lazada
• Maxis
• Gleneagles Hospital

NOTE: c denotes confirmed representation

The post Dare to Change conference in Malaysia April 2019 appeared first on The PF Group, LLC..