Search results: "development" Page 1 of 4

What are the best Agile development tools?

Agile development tools

The debate over the best Agile development tools rages on. Tools like JIRA, VersionOne, and Trello all offer different benefits. Some people love the lightweight team focused flexibility of JIRA, while others prefer VersionOne for its program management capabilities.

Long before the popularity of Agile, organizations struggled to find the right software delivery tools. Teams need tools for things like version control, defect management, test cases, reports and requirements/user stories.

It’s not uncommon to find companies using different tools to manage the different aspects of software delivery. For example, they might use Rational ClearQuest to manage defects while using HP ALM to manage test cases. Or they may use SharePoint to maintain documents while using JIRA to manage User Stories and Sprints.

Here’s the thing. There is no right or wrong combination of tools that works for your team or organization. Some teams prefer not to use any tools, and that’s okay. The real goal of self-organized teams is to produce good flow. Good flow means producing quality software that provides value to the business. It should be up to the teams to decide which tools, or lack of tools, works best for them.

 

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

The powerful benefits of value stream mapping – improving your software development process

projmgt

Value stream mapping is a powerful tool. It’s used to identify and remove bottlenecks in your organizations value stream.  Before going further about the mapping, let me first touch on what a value stream is. I’ll also describe the theory of constraints.

Your organizations value stream is the end to end process used to deliver a product to the customer. For example, it may begin as a request from a customer, and end once the customer has the finished product. The stream contains all the activities it takes to get the customer the finished product. Each activity contains a work time, and a wait time.

The theory of constraints says that the best way to optimize an organization is to focus on throughput. Throughput is the key to generating profitable revenue. The way to increase throughput is to look for the current bottleneck that is slowing things down and fix it. Once removed, find the next bottleneck and fix that. Keep this up and you will have a fast-moving value stream (Goldratt, E 1984).

Creating a value stream map – “Mapping your value stream is a good way to start discovering waste in your software development process. In industry after industry, the process of mapping the value stream has invariably led to deeper insights about how internal processes work or don’t work to meet customer needs” (Poppendieck, 2003).

An easy way to create a value stream map is to have a project team gather around the whiteboard. The process shouldn’t take long. You should be able to do this in an hour or less. Write out all key activities in your value stream. For each activity, write down how much work time it takes, and how much wait time there is.

For example, you may find it takes on average 2 weeks to code for a project, but it takes an extra 3 weeks to move the code to test. This extra 3 weeks is wait time that doesn’t provide any value to the customer. It is waste.

After creating the value stream, identify the biggest bottlenecks in your process. The goal is to increase flow and value added time in the system. Focus on the fixing the biggest bottleneck, then continue to fix the next bottleneck.

In software development, it is common to find that the biggest bottlenecks occur after development and testing are complete. This is why it’s so important for organizations to be moving towards a lean software development model.

Below is a picture of a value stream map from the book Lean Thinking, by James Womack and Daniel Jones.

 

lean-and-kanbanbased-software-development-14-638

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

References:

Mary and Tom Poppendieck, Lean Software Devleopment

Eliyahu M. Goldratt, The Goal

Top 10 influencers of the Agile software development movement

As a practitioner and student of Agile software development, I am fascinated by those who have influenced the Agile movement.

For fun, I have decided to put together my personal top 10 list of those who I believe have influenced what we refer to as Agile software development. Not only have they influenced Agile, most of them have put out bodies of work that will continue to educate future generations.

For all you Agile gurus out there, don’t freak out about who’s not on my list. You may have your own list which looks completely different. I know every time the the NFL puts out a top ten players list,  I’m usually in disagreement 🙂

Here we go…

10 -Kent Beck

 Kent Beck

Currently working for Facebook, Beck is the creator of Extreme Programming. He was one of the original contributors to the Agile Manifesto in 2001. He is a leading advocate for test driven development (TDD). Beck has published over 8 books on software development.

9 – Mary and Tom Poppendieck

Mary and Tom P

Mary and Tom are a package deal. I was fortunate enough to attend one of their workshops several years ago. Minnesota locals, the two have written together several books on lean software delivery. They helped bring lean production techniques to software development. Together they have had a big influence on the Agile movement.

8 – Jeff Sutherland

jeff_sutherland

One of my personal favorites, Sutherland is the co-creator of Scrum. A West Point graduate and pilot,  Jeff flew over a hundred missions in Vietnam. After his military carrer, Jeff got into software development. He was a doctor at the University of Colorodo school of medicine, and he helped write the Agile manifesto in 2001.

7 – Eliyahu Goldratt

Eliyahu Goldratt

Although his name may not be synonymous with software development, Goldratt has influenced the way we think about systems. Goldratt’s book “The Goal” is a required reading in almost every business school. He’s is known for his teachings on the theory of constraints (TOC) and the critical chain method.

6 – Ken Schwaber

ken_schwaber

The co-inventor of Scrum along with Sutherland, Schwaber is a prominent leader of the Agile movement. Ken has authored many books on Agile and Scrum. Ken founded Agile Alliance and Scrum Alliance, which created the Scrum master certification programs. Ken helped write the Agile manifesto in 2001.

5 – Jim Highsmith

Jim Highsmith

Jim has authored books on software development and Agile project management. He created the adaptive software development model. Jim is respected as a leader in the Agile software development movement. Jim won the Jolt award in 2000, and the Stevens award in 2005.

4 – Frederick Brooks

Frederick Brooks

Brooks is an American computer scientists widely known for his book “The Mythical Man-Month”. In his book he describes the lessons he learned while managing the development of IBMs System/360 family of computers. Brooks law states: “adding manpower to a late software project makes it later”.

3 – Taiichi Ohno

Taiichi

The father of the Toyota production system, Taiichi Ohno was the originator what we now refer to as lean. The processes and principles he put in place at Toyota had a huge influence on lean software development and Agile. Ohno claimed that he modeled the Toyota Production system after Ford, only he removed the waste.

2 – Henry Ford

Henry Ford

Ford is a fascinating American icon. He founded the ford motor company and helped create the assembly line production process. Not only did his assembly line process change the auto industry, it changed the world. Manufacturing would never be the same. What I admire the most about Ford was that he accomplished so much, and he did it all  through sheer determination.  Ford had little formal education, he didn’t graduate from High School.

1 – Edwards Deming

deming

My favorite quality guru, W. Edwards Deming. What I like the most about Deming was that he cared for the line worker. He championed pride in workmanship. He put the responsiblity on management to focus on the system. Along with a 14 point process for quality improvement, he created the PDCA (Plan, Do, Check, Act) method. The PDCA method is exactly what takes place during Scrum sprints (iterations). His processes and statistical control methods also revolutionized the Japanese auto industry.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Lean software development, trust and empowerment

once-cycling-team

Trust and empowerment are the fuel that drives high performing technology teams. Companies like Facebook, Amazon and Spotify have realized this. They all use lean software development principles. They are cutting edge Agile. They have achieved a continuous delivery framework. They deliver quality software to production almost every 11 seconds.

So what does lean software delivery have to do with trust and empowerment? You can’t adopt a lean software development framework without empowering and trusting the teams. Using lean, management tells the team the problem, but lets the team decide how to solve it. Using lean, management let’s teams deploy software to production. This means there is no wait for a release date or a release management team to deploy software.

Can you imagine, as soon as software has passed testing, it’s deployed to production? It sounds like a fantasy, but it is not. Companies like Spotify have been doing this for years. If you want to stay competitive, you need to be moving towards a lean continuous delivery model too.  

Most companies are the opposite of lean. They have long release cycles, maybe delivering new software to the customer on a monthly or quarterly basis. They follow a strict release management schedule, riddled with controls. The whole process is filled with waste that slows down the delivery of working software.

An underlying principle of lean software development is to cut waste. Waste is considered anything that doesn’t add value to the customer. If you take a good look at the software development system within your organization, odds are you will find a lot of waste. Waste only delays the delivery of working software to the customer.  

This is why management needs to let go of control. They need to empower and trust their teams. The real strength of high performing software companies comes from the teams.  Marry Poppendick, author and expert on lean software development, writes: “Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work” (Poppendieck, 2003).

Trust and empowerment are the foundation of great teams.  They are the fuel that propels the team’s forward. Trust and empowerment enable lean software development in an Agile framework. The result of lean software development is satisfied customers. Satisfied customers are the most important aspect of the software development process. When you have satisfied customers, you have achieved quality.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

4 Proven Steps For The C-Suite To Drive Greater Agility

In our current age of digital disruptions and continuous market changes, C-level executives must prepare to achieve greater agility. This is true across all industries and sectors, not only in technology. Enterprise wide flexibility has far reaching advantages, including revenue and profit increase and faster speed to market.

Achieving greater agility is not only about software development and engineering methods. It’s also about culture change, which often is the biggest road block to agility. Changing culture requires commitment from the C-level. In a recent report by PMI and Forbes Insights (Achieving Greater Agility), they surveyed C-level executives across the globe. Only 27 percent of executives surveyed considered themselves highly agile.  “In fact, culture emerges as one of the biggest hurdles to adapting to higher levels of agility, with 50 percent of respondents calling it challenging. In this light, it is troubling that only a quarter of all executives find their cultures to be strong enablers of agility.”

Below are four steps for the C-suite to drive culture change towards greater agility. These are the steps that Walmart and other large companies successfully used:

  1. Start small – For large organizations, start by using a small piecemeal approach. By creating small pockets of cultural change, you will have more success scaling. Structure small teams that are empowered and autonomous. Your odds of transformation success increase even more if you have people who will embrace agile values. Enable them to make decisions, and get out of their way. Most of all let them have fun!
  2. Teach your leaders – Management needs to learn a new way of doing things. Agility is about empowering and coaching teams. Command and control needs to go to the wayside. This is a mindset change for management that is so critical for success. Teach management to let go of control. If they don’t, it will be an absolute killer to agility.
  3. Set expectations – The Company needs to be clear about expectations for a new way of working and expect some attrition. Agile is not for everyone, and it’s best to be up front with people. If anyone wants to move on and not be part of an agile culture, that’s fine. Be clear and set expectations up front.
  4. Invest in training – You have to invest in the training so people can learn how to work in an agile environment. The key is driving out fear so smaller teams feel safe making decisions on their own. Sending people to a two day course is helpful, but not enough. Embed training and learning as part of the culture that is ongoing. Create practice groups and promote learning.

Whether you are a small company or a large enterprise, agility is the key to survival. The C-suite has a responsibility to engage and promote agility. With their efforts, driving culture change can be accomplished.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

 

 

 

 

 

5 Unique Qualities That Make Up a Great Scrum Master

The role of SM (Scrum Master) is challenging. It takes a certain type of person to succeed. As per the Scrum Guide, the SM serves the product owner, development team and the organization. The SM is a servant leader. Nobody reports to the SM.

Without formal authority, the SM relies on their natural abilities to provide leadership. People who shine as SM’s, tend to be those with high levels of social and emotional intelligence. In short, they are great with people. They build meaningful relationships and promote trust.

In no particular order, here are five unique qualities that make up a great Scrum Master:

  1. Empathy – Empathy is one of the competencies that make up emotional intelligence. It is the ability to feel the emotions of others. It creates a sense of rapport which is necessary for servant leadership. Empathy gives SM’s the ability to hone in on team members who may be frustrated or having difficulties, and help them. With empathy, the SM can see and feel someone’s struggles, without having to hear it. Great SM’s use empathy every day to gauge how the team is doing.
  2. Courage – There are two key reasons why SM’s need courage. The first is having the courage to admit mistakes. When the SM admits to a mistake and takes accountability, it sets the right example for the team. In Scrum, the team needs to understand that it’s okay to try new things and make mistakes. This promotes trust and helps to improve team performance and innovation. The second reason SM’s need courage is to protect the team. When someone interferes with the Scrum team, the SM has to confront that person. Often this can be challenging for the SM, because it could be someone with position power who is affecting the Scrum team. An example would be a manager who requests the Scrum team to do something outside of their Sprint goals. The SM needs to have the courage to confront the manager and shield the team.
  3. Coaching – The SM is a coach, and coaching is an art form. In Scrum, coaching is about asking the right questions and helping people learn. It is not about telling people what to do. Great SM’s are passionate about helping people to unlock their potential through coaching. The SM coaches the team on self-organization, cross-functionality and any areas in which Scrum is not understood. For a great book on coaching, see Coaching for Performance by John Whitmore.
  4. Discipline – Scrum is a straightforward framework. The practice of Scrum and the Scrum events are easy to understand, but difficult to master. The SM must ensure the team stays disciplined to the Scrum events. For example, great SM’s don’t blow off Sprint retrospectives or any other Scrum event. SM’s need to ensure that team members are showing up and contributing to all the Scrum events. It all starts with the SM. Great SMs lead by example, and they show up early and prepared to all the Scrum events. They never cancel events unless there’s a good reason.
  5. Facilitation – The importance of facilitation is often over looked or minimized. Have you ever attended a meeting that completely went off course due to poor facilitation? Or you had to wait 15 minutes for the meeting to start because the facilitator couldn’t get the conference bridge to work? We all have. A great SM is polished in their facilitation skills. They ensure that all Scrum events and meetings take place without a hitch. They do this by being well prepared in advance. They also use their social and communication skills to keep meetings on track, and on time. Crisp facilitation is crucial for SM’s.

Conclusion

Some people are fit to be a Scrum Master, and some are not. When managers are looking to fill a Scrum Master role, I tell them to not try and fit a person to the role. Instead, fit the role to the person. What I mean is, try to place someone who you already know is good with people. If you know someone is terrible with people, they’re not cut out to be a Scrum Master. It doesn’t matter how many certifications someone has, the SM must have emotional and social intelligence. If you can identify someone who has the five qualities I listed in this post, rest assured they have potential to be a great Scrum Master.

 

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

The Truth About the Limitation of Scrum

limitation of scrum

There is something I’d like to get off my chest. There is this notion in Agile that project management is no longer needed. Some even think that the role of a project manager will soon be extinct. Before we chase away project managers with pitch forks, lets back up a bit. I’m 100% on board with Agile and with Scrum, but I disagree that the need for project management is going away. The reason is that Scrum has a limitation. It is not designed to deliver large scale projects, at least not without help. The complexities of large scale projects demand the need for project management. This may change at some point, but I don’t see it happening any time soon. And, I’m not sure it should.

I can envision the Agile purists as they read this. Project managers needed in Agile? Scrum has limitations? Blasphemy! Hear me out.

When I refer to large scale projects, I mean projects that could have anywhere between 5-30 changed systems. These types of projects usually include complex system dependencies and a lot of coordination. The systems need to integrate and plan their production releases based on their dependencies. Someone needs to oversee that it comes together, and that someone is a project manager.

On Scrum teams, no, there is no need for a project manager. There are only three defined team roles in Scrum. They are Product Owner, Scrum Master, and the Development Team. Scrum is perfect for teams that focus only on one product or component. As an example, a Scrum team may focus on the search feature of a website.

The need for a project manager shows itself when you have large-scale initiatives. When you have a large project that impacts many Scrum teams, someone must coordinate all the dependencies between the teams. Without a project manager, who will do this? I posed this question in a recent advanced Scrum training course. I then proceeded to watch the instructor twist into a pretzel struggling to answer it. I was then referred to a course offered on Scrum@Scale.

Scrum@Scale, along with LeSS, and SAFe are the popular scaled Agile frameworks. While each of these have their benefits, they also have limitations when it comes to large scale projects. The problem is not scaling more Scrum teams, although that poses a different set of challenges. The problem is managing large scale projects.

In a recent HBR article, Agile at Scale, Jeff Sutherland and other experts discussed large scale Agile projects. They said you can establish a “team of teams” (or Scrum of Scrums), and issues that can’t be resolved can be escalated up to leaders. I’m all for that, but it still doesn’t answer the question of who is coordinating the work of all the teams? They go on in the article to reference Saab’s aeronautics business. “Aeronautics also coordinates its teams through a common rhythm of three-week sprints, a project master plan that is treated as a living document”.

I found it interesting that they referenced a company that uses a project plan in an article on scaled Scrum. This further indicates to me that we need to pause on the idea of abandoning project management.

Scrum@Scale is the model Jeff Sutherland advocates for scaling. In Scrum@Scale, there is a Chief Product Owner (CPO) and a Scrum of Scrums Master (SoSM). They are like the team level Scrum Master or Product Owner roles, but at scale. These roles sound like they will help address the challenge of managing large-scale projects, but there is still a gap. While a SoSM focuses on removing impediments and the CPO on prioritization, you still need someone to look at the project from a holistic view. Someone must coordinate team dependencies, not to mention manage risk, schedule and budget. In short, you need a project manager.

The need for project managers on large scale Agile projects has fueled the rise of SAFe. If you’ve read my post on the problem with SAFe, you know that I’m not a huge fan. But, at least SAFe acknowledges that someone needs to coordinate the work of self-organizing teams on large scale projects. They refer to the role as a Release Train Engineer (RTE), but it sounds a lot like a project manager to me.

Why do Agilest cringe when they hear the words project manager, or for that matter, the word project? When I say there is a need for project management in Agile, I am not saying that projects need to move in sequence from phase to phase like waterfall. I’m not referring to a command and control tyrant who manages Gantt charts with an iron first. Project managers today can lead large initiatives and still follow Agile principles. Projects can still use an iterative experimental process.

You may argue that by creating an architecture where each Scrum team works on an autonomous application, you end the need for a project manager. Spotify is a good example. Lightweight autonomous applications are the way to go, but you still can’t get away from dependencies on large scale projects. In most large fortune 500 organizations, legacy applications are dependent on other systems.

In summary, Scrum has a limitation when it comes to large scale projects. Project managers are not needed on Scrum teams, but they are still needed in Agile for large scale projects. What is changing is not that the Project manager role is going away. It is the role itself that is changing to align with Agile values and principles. The Scrum organizations seem to be working hard to address this limitation through their scaled frameworks, but they have a long way to go.

If you have experienced large scale Agile projects where there was no need for a project manager, I would love to hear about it. I’ve worked for many organizations that have adopted Agile and I’ve yet to come across one that had no need for project management.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Advanced Scrum Training and Meeting Jeff Sutherland

When it comes to Agile delivery, I’m a big advocate for Scrum. Scrum offers an easy to understand and lightweight framework for developing products.

Scrum is great, but it by no means is a silver bullet.  Scrum does not solve problems, it exposes them. It is like shining a big flashlight on your product development team, exposing the good, the bad, and the ugly. Scrum is an adaptive framework, not a methodology.

For most organizations, Scrum is an effective Agile framework. This is particularly true for companies new to Agile. Scrum offers a set of guide posts and rules that make it easier for organizations to get out of their own way. The rules are simple, but not easy. Anyone can get a get good understanding of Scrum by referencing the Scrum Guide.

Last week I got a great refresher on Scrum by taking the Scrum Alliance Advanced Certified Scrum Master (A-CSM) training led by Angela Johnson. Angela is passionate about Scrum, and her and her company, Collaborative Leadership Team, does a great job.

The training was a great reminder that Scrum is about people working together to deliver the highest possible value early and often.

During the training, I had the privilege of meeting and chatting with Dr  Jeff Sutherland . He was teaching a course next door on Scaled Scrum and during a break we met. While we were discussing the challenges of Agile adoption, he gave me some good insight. He told me that sometimes all it takes is one person to start an Agile movement within on organization. He said it’s like someone pulls a lever.

Dr Sutherland relates Agile transformation to the Blue Pill/Red Pill scene from the Matrix. “Take the blue pill, and go back to sleep and continue to use waterfall. Take the red pill, and stay in Agile Wonderland, and see how deep the rabbit hole goes”.

Below is a picture I took with Dr Sutherland.

 

Jeff Sutherland and Mike MacIsaac

Jeff Sutherland and Mike MacIsaac

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Embracing Change and Dotcom Operations

“The Only Thing That Is Constant Is Change” – Heraclitus

Change is necessary in business, technology, and in our personal lives. For me, these past couple of months I have had a lot of change in my life. From moving to a new home to starting a new consulting assignment, change has been abundant. While change can be unsettling, it’s necessary for growth. This brings me to latest consulting role, working in Dotcom Operations.

The picture above shows the monitoring screens located across from where I sit. As you can tell, it’s no small deal. Keeping a live production website running which handles thousands of transactions per second is no small ordeal. To do so, while also adding changes and enhancements, requires talented operations teams.

In my view, operations teams don’t get the credit they deserve. The people I’m working with in web operations are some of the most technical folks I’ve worked with. They are also good people. They are infrastructure engineers, coders, and they work with the latest DevOps technology.

It’s fun learning about the latest technology they’re using in Web Operations. Infrastructure built in the cloud using tools like Jenkins, Chef and Splunk has given me a broader perspective on IT. It’s taken me back to my days testing software in QA, but things have changed. The technical systems for web operations are more advanced than they were five years ago.

Technical systems are always challenging to manage, but what’s more challenging, are the human systems. People need to collaborate and communicate with each other, and this is where I come in to help. The effectiveness of operations teams relies heavily on communication.

To help with communication and the constant influx of work coming in, the teams use Kanban. Kanban uses a pull system to make process better. Below is an example of what you may have seen with a Kanban board.

The core practices of Kanban are as follows:

  • Visualize Workflow – Using Kanban, teams can see the whole visual representation of their workflow.
  • Limit WIP (work in progress/process) – Teams should experiment with WIP limits, which will help improve focus and increase throughput.
  • Manage Flow – By paying attention to how quickly work is getting through the process, teams can begin to improve flow management.
  • Make Process Policies Explicit – Teams should set their own policies on how they can best do their work and improve flow.
  • Implement Feedback Loops – This is about continuous improvement. Just like in Scrum, Kanban teams need to measure their effectiveness and continuously improve.
  • Improve Collaboratively, Evolve Experimentally

Kanban comes from manufacturing and the TPS (Toyota Production System). The below quote is from Taiichi Ohno, creator of the TPS:

“There is no magic method. Rather, a total management system is needed that develops human ability to its fullest capacity to best enhance creativity and fruitfulness, to utilize facilities and machines well, and to eliminate all waste.”

Eliminating waste was a major rule of the original TPS. TPS identified seven types of waste in manufacturing. They are Transportation, Waiting, Motion, Defects, Inventory, Overproduction and Extra Processing.

Years later, Mary and Tom Poppendieck defined the following seven categories for waste in software development.

  • Partially done work
  • Extra processes
  • Extra features
  • Task switching
  • Waiting
  • Motion
  • Defects

An effective way of identifying waste for is through creating Value Stream Maps. Often the biggest bottlenecks occur after development and testing are complete.

Summary

Over the past few years I’ve managed a broad range of IT projects. From working in the insurance industry, to reverse logistics programs, to Web Operations. While this work has commonalities, Web Operations is different. Tackling a constant flow of work is a change for me, and change is good. The change to Web Operations has provided me with two key opportunities. The first and most important, is to provide value and help a talented team of engineers. The second is to learn a different aspect of IT and business.

Are you embracing change in your business and in your life? If you work in software development, are you continually trying to reduce waste and follow lean principles?

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

 

 

 

 

 

 

 

A Fun Day in Minneapolis – Agile Day Twin Cities 2017

Agile Day Twin Cities

Yesterday I had the pleasure of attending the Agile Day Twin Cities 2017 conference, sponsored by DevJam. The conference aims at helping Minneapolis Agile practitioners learn from each other.   Throughout the day there were breakout sessions which featured different speakers. The talks ranged from the people and business of Agile, to new ideas about improving Agile development.

As David Hussman, the founder of DevJam, kicked off the event, I was impressed by the theme and feel. David made it clear that the event was not about experts and teachers, but instead about learning from each other and challenging the status quo. David also emphasized a focus on product, rather than process. As the event got under way, I was struck by the impressive crowd of Minneapolis Agile practitioners. Minneapolis has become a tech hub and a melting pot for startups, innovation, and entrepreneurship.

Throughout the day I attended many sessions. I heard from other Agile practitioners sharing their experiences. Minneapolis being the small town that it is, I ran into many friends and some former colleagues. One of the highlights was hearing Priya Senthilkumar and Ray Grimmer, former colleagues from my days at PearsonVUE. Priya and Ray talked about their journey implementing stable Agile delivery in a complex environment.

Another talk I enjoyed came from Daniel Walsh. Daniel talked about improving Agile development using the Cynefin framework. Cynefin (pronounced KUN-if-in), Welsh for habitat, was developed in the early 2000s and used as a sense making device. The Cynefin framework has four areas of decision-making: simple, complicated, complex, chaotic, and at the center is disorder. Below is a picture of the Cynefin quadrant with actions for how to respond to each situation.

My take away from the Cynefin framework, is that not all Agile concepts will work well in situations. We need to understand why and where our practices work, and get away from asking questions like, is Scrum better than Kanban? This is the wrong question to ask. We should be asking, what is the situation we are dealing with, and how should we respond to it? We need to get away from a single, recipe based approach for all situations. The way we work in Agile needs to be fluid and smart, and not dogmatic and one size fits all.

I could relate to the concept of the Cynefin framework. I’m sure I’ve been guilty of pushing the wrong Agile framework in past situations. I’ve worked with organizations where Scrum fit like a glove, and in other companies Scrum felt like trying to fit a square piece in a round hole. As the Agile movement continues to evolve, we need to be open to new approaches, ideas and methods.

In summary, my time at Agile Day Twin Cities 2017 was great because it challenged my way of thinking. Sometimes we get so caught up in our work and opinions that we forget to step back and look at things from a different perspective. The new ideas and concepts I heard at Agile Day Twin Cities were great. Perhaps what I enjoyed the most, was connecting with other fellow Agile practitioners.

Below are a few pictures I took during the conference.

Agile Day Twin Cities

David Hussman kicking off the day

Priya Senthilkumar and Ray Grimmer: Agile at Pearson VUE

Daniel Walsh: Improve Agile Development Using the Cynefin Framework

MC Legault: Agile is People & Business!

About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog

 

 

Page 1 of 4

Powered by WordPress & Theme by Anders Norén