Search results: "development" Page 2 of 4

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

 

 

6 Steps To Take Before Making The Agile Transformation Plunge

With the popularity of Agile, more and more executives are pushing Agile transformation. To meet this demand, everywhere you look someone is now selling Agile. In a sense, Agile has become a commodity.

Agile Transformation

Those selling the commodity offer things like Agile coaches, Scrum training, and SAFe certifications, just to name a few. Don’t get me wrong, many of these vendors provide high quality services. The commoditization of Agile is a result of demand due to the positive brand that is “Agile”. When done right, few will disagree that Agile isn’t the best way to develop software.

When it comes to Agile transformation, the problem is not so much the Agile service providers, but more so around a lack of planning. Without proper planning,  the “transformation” process often goes over like a lead balloon.

The scenario usually goes something like this: executive from company X declares the organization needs to be Agile. Management then scrambles and hires Agile coaches and force employees to sit in open-work spaces. Throw in some team stand-ups and burn down charts and voila, they are now Agile! Management is happy, that is, until time goes by and they realize they have no measurable improvements.

Here’s the thing, Agile transformation is a huge change. If you haven’t properly planned before charging into transformation, your chances of success will be slim.

Another way to think of Agile transformation is like getting yourself in good physical shape. Last year I started working with a personal trainer. When I first met with my trainer, he didn’t send me right into the weight room and have me do dead lifts and squats. Instead, we met on multiple occasions and talked through my eating habits, my fitness routine, and my goals. We did this before I went anywhere near the weights.

By taking the time to do the analysis, I got a clear picture of where the problems were with my current fitness routine (or lack thereof) and diet. This enabled me to come up with goals and a manageable plan to achieve them. I was then able to put the plan into action and with the help of the trainer, receive some great results.

It’s the same with Agile transformation. You need to take the time to analyze and plan before charging ahead. If you’re planning to bring in Scrum training and Agile coaches, I’d like to propose some steps to take before doing so. Below I have outlined 6 steps intended to help you be successful in your Agile transformation journey. Think of them as Agile transformation prerequisites.

1) Know Your Organizational Purpose – Make sure you are clear on what your definite purpose is as an organization. You might be asking, how is the purpose of my company related to Agile, isn’t Agile an IT thing? It’s funny, many of us in technology sometimes forget we are part of a bigger picture. Business and IT must be aligned on the definite purpose of the company. If you don’t know the purpose of your company, then you have a bigger problem to deal with then adopting Agile. By knowing the definite purpose of the organization, you can align your Agile transformation strategy with the mission and goals of the company.

2) Know Your Current Value Stream – Get a clear picture of your current end to end process for delivering product or service. Many companies have different departments responsible for their part in the sausage making, yet nobody understands the full end to end process. Remember, if you’re going to make improvements, first you need to understand what needs to be improved. Saying that you want to become more Agile is not good enough. That’s like going to a trainer and saying that you want to be healthier. You need to get specific and find out what’s going on.

One way to do this is to sit in a room with management and white board out your current end to end process. Start from the beginning of new product idea, or customer order, all the way until the product or service is in the hands of your customer. This includes your business funding and prioritization process, and project planning and delivery. Include all your processes and steps for delivering your product and service. While you are doing this, write down the actual work time it takes to complete each step in the process, as well as the wait time. What you’re doing at this point is getting a clear picture of your delivery process, while also identify constraints in your system. For more on the benefits of this process, see my post on the theory of constraints and value stream mapping.

3) Know your constraints – The next step is to identify the clear bottlenecks in your delivery process. For example, if you find that on average it takes your company 1 year to approve new projects for funding, you’ll know you have a constraint way up-stream in your delivery process. Agile transformation is not only about making changes to your IT teams, it’s also about changing how your business operates. The idea is to be lean and efficient while providing high quality products to your customer.

4) Know your employees – Take a good look at your people. Are they open to change? Do they bring a positive attitude and contribute to a healthy culture? How about your IT people, are things like paired program and test driven development foreign concepts to them? Take a good inventory of the soft and hard skills of your employees. This is important because if you don’t have the right people, your Agile transformation efforts will fall flat. Get to know how your people really feel about Agile. What you don’t want is people who pretend to be on board with Agile, but bad mouth it at the water cooler.

In my experience, if you have people who are open and willing change, and are positive, you’ll be in good shape. You can teach the technical skills but trying to change someone’s attitude is a whole other ball game. Agile is all about collaboration and working as a team. You need great team players.

5) Know your technology – Analyze your current applications and delivery system. What type of infrastructure do you have in place? What’s your technology stack? Are you using physical or virtual servers? Are you using cloud technology? Take the time to do a full inventory of your technology and its health. How about your testing and deployment capabilities, are you running any automation? You need to know what kind of technology you’re working with. If you company uses archaic technology, it may be time to upgrade. Agile is a modern software delivery practice, you should aim to complement it with modern technology.

6) Create goals and an action plan for Agile transformation – After doing a thorough analysis of steps 1-5,  now you’re ready to create a tailored action plan with goals. This is where you decide what Agile framework to use, or combination of frameworks. At this stage you are now ready to engage outside help for Agile training and coaching, based on your goals.

By going through all the steps, you may be surprised what you discover. Your teams may be more Agile than you think. Only through proper analysis can you discover what is working and what needs to change.

If all this seems too daunting, or if you have already brought in Agile coaches yet see little change, at MacIsaac Consulting we can help. We act as trusted advisers to help organizations put the right Agile transformation plan in place.

We are Agile framework agnostic. Our goal is to tailor a plan that what works best for your company. With Agile transformation, it shouldn’t be a one size fits all approach. Just like someone’s fitness goals, each organization will have different goals and strategies to achieve them.

So take the proper steps, because you and your organization deserve a successful Agile transformation!

About the Author: Mike MacIsaac is the president and principal consultant for MacIsaac 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.

 

 

Everyone On The Delivery Team Is Responsible For Quality


When it comes to software quality assurance, most people think of phase at the end of a project. This testing phase is usually performed by “quality assurance” testers. The traditional project delivery model is to blame for this. As someone who worked as a software tester for years, I know about the pains of doing all testing at the end.

The problem of course is that when testing happens at the end, after a development phase, it is too late. What you are doing is trying to inspect quality in, instead of building quality in.

Lean manufacturing and lean software development is about building quality in. This was one of W. Edwards Deming’s, a pioneer in the lean and quality movement, motto’s . To build quality in, testing should take place all throughout the project. Testing early reduces the cost of defects because the earlier you catch defects, the cheaper they are to fix.

For this reason, it is well advised for software delivery teams to apply lean principles and automate as much as possible. Automation shouldn’t only be a set of regression tests that run at the end. Automation should take place all throughout the entire software development and release process.

Automation can begin in development using test driven development (TDD). For more on TDD, see my post on why automated testing is needed early and often.

After TDD, automation can be applied from build and deploy to acceptance tests.

This brings us to the process of Continuous Delivery. Continuous delivery is all about creating reliable software releases through build, test, and deployment automation. Today, more software organizations are reaping the benefits of continuous delivery, yet for most it’s still a pipe dream.

People think the idea of automating everything is too daunting, or can’t be done for their application. More and more we are now seeing that continuous delivery can be done, for any application or organization, no matter the size. A good way to start is by looking at your current release process, and finding the biggest bottlenecks. You can then start to automate over time, targeting the bottlenecks first.

By automating the whole software release process, you build quality in. This makes everybody on the delivery team responsible for quality, not just a “QA” team who tests at the end. For manual software testers, continuous delivery enables them to focus on exploratory testing.

There are many other benefits to TDD and continuous delivery, but perhaps the greatest is the reduction of stress for delivery teams. If you’ve gone through a production deployment process, using manual processes and ad-hoc configuration techniques, you know what I’m talking about.

For those who already use lean development techniques this information shouldn’t be news to you. If you still work in an environment that uses SDLC processes with little to no automation, the topics I’ve covered only scratch the surface.

Some great books I recommend on lean software development and continuous delivery:

By using continuous delivery and automating as much as possible, everyone on the delivery team is responsible for quality.

About the Author: Mike MacIsaac is the president 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.

 

Why I Love Agile (And You Should, Too!)

After recently starting a new consulting engagement as an IT program manager, I’m reminded why I love Agile.

I love Agile

 

For most companies, sticking with a Waterfall software delivery model is like being in a bad relationship. No matter how much you know and feel something is wrong, you keep going back to it.

It could be due to the comfort of the familiar. Sometimes the idea of changing to something unfamiliar is too frightening, even when we know we should.

One of the major problems I see with Waterfall is that it sets the stage for people to work against each other. Each phase in Waterfall provides the perfect recipe for friction among people who are afraid. What are they afraid of? They’re afraid of being blamed if things go wrong.

What if the project fails and they blame it on my requirements? What if they blame it on my software design? What if they blame it on my development or testing? The result of this fear is people working against each other.

In Agile you break down the barriers of fear and distrust by bringing people together into cross functional teams. When we bring the different phases and groups together into one unified process, we can achieve great things.

Agile is about people collaborating and connecting with empathy, while creating synergy to achieve a common goal. In my humble opinion, the greatest benefit of Agile is that it brings people together. That is why I love Agile.

About the Author: Mike MacIsaac is the president 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.

12 Ways Management Can Empower Teams And Create Agility

empower teams

Mike MacIsaac – President at MacIsaac Consulting Inc

With the advance of technology and globalization, organizations today must have agility. It doesn’t matter the industry, companies need to be able to adapt to change. As a consultant, I’ve seen this need first hand throughout the tech, retail, and financial industries.

Gone are the days when different departments within a company worked in silos. Companies who still do this, and use a static organization structure, will struggle to survive. They will fall to the competitive advantage of the agile organization.

The problems faced by companies today are too complex to not be agile.  The pressure put on from external forces demand a new way of thinking and collaborating.

One way to create agility is through the use of decentralized cross-functional teams (CFTs).  A CFT is a team made up of people from different functional areas within the company. These experts work together to achieve a common goal. Over time the team develops synergy, and becomes high performing. Team synergy vastly exceeds the productivity of individual efforts.

When management empowers CFTs to make decisions and self-organize, the teams move fast, really fast. Team autonomy and empowerment promotes an atmosphere of trust, creativity, and worker satisfaction.

One of the greatest benefits of empowered CFTs is their ability to manage chaos. This phenomenon is counter intuitive to our natural reaction to manage chaos. Most of what we learn in business school aligns with the carrot and stick style of management. The more things get out of control, the more we tighten up our grip on the team. As managers, we have to let go of this notion of command and control. We can empower teams while still holding them accountable.

In a recent HBR article, Michael Mankins and Eric Garton describe how Spotify balances employee autonomy and accountability. They write “Companies that take the approach of empowering autonomous teams must find ways to ensure that coordination and connectivity happen among those teams without relying on controlling managers. Again, it’s a matter of managerial art as well as science to achieve alignment without excessive control.”

If you assemble a CFT with people new to such an environment, there will be a learning curve. You can’t expect people to self-organize and make decisions when they are used to being controlled.  The key is for CFTs and management to learn a new way of thinking, but this takes time.

Ken Schwaber, who formed the Agile Scrum framework along with Jeff Sutherland, writes “A team requires concrete experience before it can truly understand how to manage itself and take the responsibility and authority for planning and conducting its own activities.”

Below are 12 principles that can help management develop high performing cross-functional teams:

  1. Create stable cross-functional teams – Creating stable CFTs, dedicated to long-term goals, is necessary for high performance, quality and innovation. To do this you must dedicate resources and provide constant training. Each team member must have knowledge and expertise in a certain functional area. Changing team resources and not allocating for long-term planning is a killer to team performance.
  2. Provide a clear and compelling purpose – People suffer when they lack purpose. It is the responsibility of management to provide a purpose. People need a purpose because it creates intrinsic motivation. If employees are assigned tasks that have no meaning to them, they will lack motivation. Management should communicate how the goals of the team align with the long-term goals of the company.
  3. Protect the teams – Run interference and protect CFTs from distractions and skeptics. Management must be committed to the overall purpose of the organization and the CFT. There are always skeptics and people who are resistant to change. It is well advised for management to not include these types on change efforts and new CFTs. Skeptics will cause more harm than good. Staff CFTs with people with positive attitudes who will champion the goals of the team and organization.
  4. Give teams the help they ask for – With the high performing CFT model, managers don’t tell the team how to do their job. Instead, the teams tell management what they need to be successful. It is the job of management to listen to these requests and do their best to provide the teams with the help they ask for. Again, just because management is not telling teams what to do, it doesn’t mean they shouldn’t hold teams accountable.
  5. Empower teams to make decisions – Management can hold teams accountable for results, but they need to empower teams to make decisions. The decentralization of authority allows teams and organizations to produce results fast while responding to change. Management is still responsible for telling teams what needs to be done, but the teams are responsible for how it will be done.
  6. Allow mistakes to be made – Encourage teams to accomplish stretch goals, but do not punish if everything is not achieved. It’s important for management to help drive out fear. When employees are afraid of being punished for mistakes, it kills innovation. The important thing is learning from mistakes. Teams should continually take inventory on how they can improve.
  7. Use information radiators – On CFTs, everyone needs to see what’s going on and what needs to be done. Having a board that displays visual controls enables and promotes teams to self-direct. Information radiators also let management and outside stakeholders view how the team is doing and how much work is in progress.
  8. Deliver as fast as possible – Fast product delivery results in increased business flexibility and happy customers. Short value streams eliminate waste and they allow decisions to be delayed. Management should promote the idea of delivering valuable products fast. Often time’s people think that you can’t deliver fast without compromising quality. This is not the case when you build quality and integrity into product development. The fast delivery system does not compromise on quality; in fact it improves quality because consumers get the product faster. This enables consumers to provide feedback sooner which can go back into the design of the product, improving quality.
  9. Analyze and improve throughput – The best way to optimize an organization is to focus on throughput. The theory of constraints teaches us to find bottlenecks in the system and fix them. Teams should continue analyzing the system, identifying bottlenecks, and removing them. When teams focus on improving non bottleneck areas of the system, it doesn’t help improve throughput. Following the theory of constraints principle, teams can delivery fast.
  10. Promote quality built into products – In Edward Deming’s book “Out of the Crisis” he writes “Quality comes not from inspection but from improvement of the production process. Inspection, scrap, downgrading and rework are not corrective action on the process”. This means for software development, we need to get away from this notion that QA is this separate process that happens after software development. We should not be inspecting quality into the software through QA. Instead, QA should be happening as part of software development through the use of test driven development and automation. This enables quality to be built up front, instead of through inspection.
  11. Improve quality by learning from the consumer – In the Agile software development “Scrum” we do product reviews continually with the consumer. This same principle can be implemented throughout the organization. The goal is to feed the consumer reactions and feedback back into the design of the product to improve quality.
  12. Provide servant leadership – In Scrum, the Scrum Master acts a servant leader. The Scrum Master job is to remove impediments and help the team. This servant leadership practice is a great example for management to emulate. By supporting and helping teams, you foster at atmosphere of empowerment and trust.

For many organizations, the points I listed may be a significant change from their current reality. It’s not easy to put in place all these changes. Even for the modern agile company, agility is an ongoing learning process. If your organization needs guidance, at MacIsaac Consulting we are here to help. From advising leadership, to providing resources, we can guide you on your agile transformation journey.

About the Author: Mike MacIsaac is the president 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.

References

Deming, E. (1982). Out Of The Crisis. Cambridge, MA: MIT.

Mankins, M & Garton, E (2017). How Spotify Balances Employee Autonomy And Accountability. https://hbr.org/2017/02/how-spotify-balances-employee-autonomy-and-accountability

Poppendieck, M. (2003). Lean Software Development. Upper Saddle River, NJ: Pearson Education.

Schwaber, K. (2004). Agile Project Management With Scrum. Redmond, WA: Microsoft Press.

 

Kanban vs Scrum – What You Need To Know

Kanban vs Scrum

If you are familiar with Agile you know about Scrum and Kanban. While these two Agile frameworks have similarities, they are also very different. Their differences go way beyond stickies on boards. In this post I’ll describe the two frameworks and their history, as well as their benefits and differences.

Scrum OverviewScrum is by far the most used Agile framework. Credit for the framework goes to Jeff Sutherland and Ken Schwaber. Scrum got under way back in 2001 after the creation of the Agile manifesto.

Scrum is great for complex software delivery projects. In Scrum, there are defined team roles which are Product Owner, Scrum Master, and development team. The Product Owner creates a backlog of user stories that define the scope of a project. The team then completes the stories in short iterations called “sprints”. Sprints usually last 2-4 weeks. Sutherland was influenced by his days as an Air Force pilot. He relates the team sprints process to coming back from short missions and landing the plane on time.

The goal is to have working software, approved by the Product Owner, at the end of each sprint. The stories worked on in the Sprint should be done (all testing completed..etc). The key metric used in Scrum is Velocity. Velocity is the average amount of points a team can complete in a Sprint. Within Sprints, change to work is discouraged.

The stories completed in each sprint represent part of the total project scope. The team repeats this cycle of sprints until all stories in the backlog are done, in which case the project ends.

Kanban Overview  – “Kanban” get’s its origins from the Toyota Production System. Back in the 1950s, Taiichi Ohno created a pull system for Toyota. The idea was first sparked by his experience in American supermarkets. He was fascinated by how shoppers would walk down the ails pulling only what they needed from the shelves and putting it into their shopping carts. Shoppers usually had a list they carried which told them what they needed.

In Toyota plants, “Kanban” are instructions in clear plastic that communicate information needed at work stations. In a sense, a Kanban is like a grocery list. When an order comes in, a Kanban would be used to pull the whole car creation process together. Each item needed for the Kanban is ready just in time (JIT). This enables minimal build up of inventory. In a lean system, the goal is to reduce waste. The build up of inventory is the worst form of waste according to Taiichi Ohno.

The principles of the Toyota Production system were emulated in lean software development when Kent Beck created XP (Extreme Programming). The goal was to use the JIT principles and limit work in progress to the teams capacity. Beck also implemented a test driven development (TDD) process that improved quality. XP can be considered a different Agile framework from Scrum and Kanban. In my view, XP has more of relation to Kanban, since Beck based most of the practice off of Ohno’s Kanban method.

Unlike Scrum, Kanban is usually not the framework of choice for software delivery projects. Projects have a clear beginning and end, as well as a defined scope. Kanban works well for support teams, where work will be ongoing.

Teams will use a Kanban board, like the board a Scrum team would use for their Sprint. There are no Sprints in Kanban, the work is a continuous flow. There are also no defined roles in Kanban, like there is in Scrum. Cycle time is the key metric used and unlike the Sprints in Scrum, in Kanban change can happen at anytime.

Some of the benefits of Kanban include flexibility in planning, increased throughput, fewer bottlenecks and visual metrics. Kanban also compliments continuous delivery.

Below is a grid that Dan Radigan from Atlasssian put together, which displays the differences between Kanban and Scrum.

                                          Scrum                                                             Kanban

Cadence Regular fixed length sprints (ie, 2 weeks) Continuous flow
Release methodology At the end of each sprint if approved by the product owner Continuous delivery or at the team’s discretion
Roles Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach.
Key metrics Velocity Cycle time
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time

Summary

Scrum and Kanban are two different Agile frameworks, but both have many benefits. In my view, Kanban is more aligned with lean development than Scrum. The area where Scrum gets into trouble with lean is the idea of having a team create and work on a large backlog. Lean experts, like Mary Poppendieck, cringe when they hear the word backlog. This is because it goes against the principles of JIT and low inventory. At Toyota, I’m sure the plant manager would freak if they had a large backlog of orders piling up. They want to have low inventory and good throughput. While Kanban works great for a repeatable process, my view is that Scrum is the best framework for complex software delivery projects.

If you enjoyed this post, check out The Top 10 Influencers of Agile.

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.

 

Adapting to change, the Agile organization

Organizations today must be Agile to deal with the rapid pace of change due to globalization and technology. In software development, we have seen how well cross functional Agile teams can deliver value.

Companies that adopt this same level of agility across their enterprise will be well served. I’m not talking about scaled Agile or some framework. I’m talking about organizations that can change and adapt. They are like clay instead of rocks. Agility provides a level of flexibility and adaptability that gives them a competitive advantage.

Below is a short talk from John Kotter in which he discusses the differences between the network and the hierarchy, and how they can coexist. In my view, organizational structures of the future will look less like hierarchies, and more like solar systems (networks).

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.

 

Self-organizing teams produce the best architectures, requirements, and designs

Self-organizing teams produce the best architectures, requirements, and designs.

self-organized team

The above statement is one of the principles behind the Agile Manifesto. Too many “Agile” teams struggle to get this concept.  They have the Agile ceremonies down, and they may even sit together, but they still work in silos based on waterfall principles.

The following statements are all signs that a team is struggling to adopt the Agile self-organizing team behavior:

  • “I can’t work on the design because the requirements aren’t complete yet.”
  • “I can’t create any test scenarios yet because the design is not complete.”
  • “I can’t start development, I have to complete a design document first. “

In Waterfall, the requirements and design process looks like this:

In Agile, it looks more like this:

It’s a cluster of work that happens together. The process gets messy and entangled, in a good way. There are no long drawn out separate phases of development or QA. All the work is happening together, and cross functional team members collaborate through the whole process.

When the team is self organized, that’s when great ideas and valuable products emerge. Why wait for a long period of time for requirements to be completed by a BA, only to be reviewed by the team at a later date? Or wait for a design or dev to be completed, only to be reviewed later?

As Deming used to say, you don’t inspect quality into a product, quality is built-in up front.  Why not use that same principle for how we treat requirements/stories, designs and tests? Instead of inspect quality into them, let’s build the quality in up front by having all team members contribute to the work.

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.

Definition of done, what it means and why it’s important

Understanding the definition of done.

definition of done

What is your definition of done? This is a question you often here in Agile software development. In this post I’ll take a closer look at what the question means, and why it’s so important.

Let’s backup, in Scrum the goal is to have potentially shippable product increments at the end of each sprint. “Potentially shippable” means the code is ready to deploy to production if needed. The code should provide some value to the customer or end-user.

The work within the sprint is broken down into user stories. Each story represents a feature or piece of functionality that provides value to the customer.  In order for user stories to be “done”, the following acceptance criteria should be met:

  • Code designed, built and unit tested
  • Code passed some forms of functional, integration, regression and acceptance testing

To speed up the process of “getting to done”, most software groups invest (or should) in automated deployments and automated testing.

But what if we have non development stories, how do we create a definition of done for those?

Some Scrum teams aren’t only delivering software. Here’s my take on defining done/acceptance criteria for non development user stories:

Always aim to have something tangible to show by the end of the sprint. Each story you work on should produce, or contribute to producing, a valuable output. It could be a document, spreadsheet or some other else. Whatever it is, it should be a tangible/completed item that item that provides value.

Remember, much of Agile is based on lean principles. In lean, anything you are working on that does not provide value to the customer is considered waste. The goal in lean systems is to cut waste, reduce constraints, and increase valuable throughput.

So when you are creating your definition of done, ask yourself these questions:

  • If it’s code related, what will it take to be production ready?
  • Whether its code related or not, what will it take to get it demo-ready? Is it tangible and will it provide value?
  • Does the team agree upon what it takes to be done?

What will happen if we don’t create a definition of done for our user stories?

Not having a definition of done for your user stories is a common problem. When this happens, teams usually pull more stories into the sprint than they can handle. They do this because they don’t realize what it takes to actually complete stories. The result is tons of work in progress with nothing getting completed. The more WIP you have, the less valuable output produced.

The increase of WIP is the most devastating effect of not creating a definition of done for your user stories. Nothing will slow down flow more than jamming the pipeline with user stories that don’t have clear acceptance criteria.

Next time you have a Sprint Planning meeting, review your stories to ensure the team knows the definition of done. Even if the team realizes they can only work on 1 story, if at the end of the sprint they have something completed that provides value to the customer, you’re on the right track!

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 identity crisis of the IT project manager

The IT project manager role is one of the most in demand and sought after positions in technology. Ask any hiring manager and they will tell you that finding a good IT project manager is difficult. I’ve seen people with the most impressive credentials crash and burn trying to manage IT projects.

So what exactly is an IT project manager, and what makes a good one? The IT project manager used to be the person accountable for managing scope, schedule, and budget for IT projects. Today, that’s still true, for the most part, but the role has a bit of an identity crisis

The Project Management Institute, with their PMP certification, says the role is all about planning and control. If you’ve taken the PMP exam, you know PMI teaches you to create a large project plan. Within that plan are many sub plans for each area of the project.

The PMI has come under scrutiny in recent years by the technology community, and for good reason. With the rapid advancement of technology and globalization, organizations need to be agile. Planning is important, but responding to change may be even more important. Our systems and organizations have become too complex for the PMI plan and control model. This need to adapt to change is what has fueled the Agile software development movement.

With the increase of self-organizing agile teams, it brings us back to the question, what is the role of the IT project manager? Is it an Agile project manager? Is it a project leader? Is it a servant leader? Is it a Scrum Master? Is it a tech lead?

The answer depends, but the role may consist of a combination of all these things. One thing we know for sure is that the IT project manager is a change agent and a leader.

To succeed in this role, one needs to have both hard and soft skills. Good IT project managers use both the left and right hemispheres of their brain. The right side of the brain used for cognitive thinking, the left side for emotional intelligence and relationships. This enables them to be both technical, and emotionally intelligent. Project management is both a science and an art form.

If you are looking to get into IT Project management, you better be able to deal with chaos while keeping your cool. If you currently work as an IT business analyst, tester, or developer, you are well prepped for IT project management. I began my career in QA, and my experience in testing has been invaluable to my role as an IT project manager.

The reason people in these roles make good IT project managers is because they are battle tested. They know what it’s like to be in the trenches of IT projects, and to come out on the other side.

Let’s face it, delivering IT projects is tough. Business executives often don’t realize how tough it is. They are like patrons in a restaurant ordering a four-course meal. As they sit in the dining hall waiting for their meal, agitated by any delay, they don’t see the chaos in the kitchen.

It’s the job of the IT project manager to manage the chaos while portraying calmness and confidence to the team and business. Managing the chaos and leading the project to completion is what makes the IT project manager so valuable.

For me, I enjoy the chaos that comes with delivering IT projects. I particularly like the areas of development and testing. If you love technology, working with others, and solving complex problems, the IT project manager role may be a great fit.

So although the identity of the IT project manager is hard to define, it’s an exciting time for the field. With the rapid advancement in technology and globalization, the demand for good IT project managers will continue to go up.

We have only begun to scratch the surface of the digital world. AI, IoT, and big data technologies are in their infancy. As we chart a course into unknown territories of the digital world, we need good IT project managers to lead the way!

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.

Page 2 of 4

Powered by WordPress & Theme by Anders Norén