I recently read an article by Jason Little entitled, “Yes, There are Agile Best Practices.”
He acknowledges that the Agile community hates the term but continues to assert that, “it’s more about the implementation of the practices as opposed to the practices themselves. [For example] Having Daily Standups, Retrospectives and Demos/Sprint Reviews are non-negotiable starting points for any team new to Agile. You don’t necessarily need to co-locate, or strip everyone of their titles, or even be Agile. The easiest way to get started when you’re new is to do these 3 best practices. How and when you do them is what will need to be adjusted over time, but not doing these 3 best practices means there’s not much point in getting started with Agile in the first place.”
He has a good point. No sense in doing best practices just for the sake of saying they are done. It’s pointless.
Any Agile team would want to include these 3 practices into their routine, otherwise they are not really considered an Agile team.
His article was informative and I enjoyed the read.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
I was at an experience report at Agile 2016 last week, Scaling Without Frameworks-Ultimate Experience Report. One of the authors, Daniel Vacanti said this:
Flow focuses on unblocking work. Iterations (too often) focus on the person doing the work.
At the time, I did not know Daniel’s twitter handle. I now do. Sorry for not cc’ing you, Daniel.
Here’s the issue. Iteration-based agile, such as Scrum, limits work in progress by managing the scope of work the team commits to in an iteration. Scrum does not say, “Please pair, swarm or mob to get the best throughput.”
When the team walks the board asking the traditional three questions, it can feel as if people point fingers at them. “Why aren’t you done with your work?” Or, “You’ve been working on that forever…” Neither of those questions/comments is helpful. In Manage It! I suggested iteration-based teams change the questions to:
- What did you complete today?
- What are you working on now?
- What impediments do you have?
Dan and Prateek discussed the fiinger-pointing, blame, and inability to estimate properly as problems. The teams decided to move to flow-based agile.
In flow-based agile, the team creates a board of their flow and WIP (work in progress) limits. The visualization of the work and the WIP limits manage the scope of work for the team.
Often—and not all the time—the team learns to pair, swarm, or mob because of the WIP limits.
Iteration-based agile and flow-based agile both manage the team’s work in progress. Sometimes, iteration-based agile is more helpful because the iterations provide a natural cadence for demos and retrospectives.
Sometimes, flow-based agile is more helpful because the team can manage interruptions to the project-based work.
Neither is better in all cases. Both have their uses. I use personal kanban inside one-week iterations to manage my work and make sure I reflect on a regular basis. (I recommend this approach in Manage Your Job Search.)
In the experience report, Daniel and Prateek SIngh spoke about the problems they encountered with iteration-based agile. In iterations, the team focused on the person doing the work. People took stories alone. The team had trouble estimating the work so that it would fit into one iteration. When the team moved to flow-based agile, the stories settled into a more normalized pattern. (Their report is so interesting. I suggest you read it. Page down to the attachment and read the paper.)
The tyranny was that the people in teams each took a story alone. One person was responsible for a story. That person might have several stories open. When they walked the board, it was about that one person’s progress. The team focused on the people, not on moving stories across the board.
When they moved to flow, they focused on moving stories across the board, not the person doing the stories. They moved from one person/one story to one team/a couple of stories. Huge change.
One of the people who read that tweet was concerned that it was an unfair comparison between bad iterations and good flow. What would bad flow look like?
I’ve seen bad flow look like waterfall: the team does analysis, architecture, design specs, functional specs, coding, testing in that order. No, that’s not agile. The team I’m thinking of had no WIP limits. The only good thing about their board was that they visualized the work. They did not have WIP limits. The architect laid down the law for every feature. The team felt as if they were straightjacketed. No fun in that team.
You can make agile work for you, regardless of whether you use iterations or kanban. You can also subvert agile regardless of what you use. It all depends on what you measure and what the management rewards. (Agile is a cultural change, not merely a project management framework.)
If you have fallen into the “everyone takes their own story” trap, consider a kanban board. If you have a ton of work in progress, consider using iterations and WIP limits to see finished features more often. If you never retrospect as a team, consider using iterations to provide you a natural cadence for retrospectives.
As you think about how you use agile in your organization, know that there is no one right way for all teams. Each team needs the flexibility to design its own board and see how to manage the scope of work for a given time, and how to see the flow of finished features. I recommend you consider what iterations and flow will buy you.
If you missed Mike Cottmeyer’s presentation at Agile 2016 last week, you can check out the video podcast interview we did with him following his session. On the first day of the conference, Mike presented his session – An Executive’s Step-by-Step Guide to Leading Large-Scale Agile Transformation. The presentation was well attended with over 400+/- attendees in the audience. Thanks again to everyone who made it out to Mike’s talk.
Agile 2016 Slide Deck
If you’d like to check out Mike’s presentation deck from Agile 2016, you can find it here. Once the actual presentation is posted to the Agile Alliance website we’ll have an updated link here.
The post Agile 2016 Video Podcast Interview with Mike Cottmeyer appeared first on LeadingAgile.
In a business context, My Personal Scrum can enable managers and their staff to achieve high alignment and transparency about goals, forecasts and milestones achieved. In a personal context, spouses and partners can coach each other to set and achieve objectives together. And as a coach, you can use My Personal Scrum to enable your clients to identify and work toward their important goals in life and work.
Why My Personal Scrum?It takes just as much time to flip a quarter as to flip a penny, but the quarter is more valuable. So where should you invest your time? On the quarters, i.e on the things that bring value to you.
Sometimes resting or "chilling" is the right thing to do, and that's OK too. My Personal Scrum doesn't try to tell you what's important; it just helps you to recognize what's important to you, so you can do the right thing.
My Personal Scrum enables you ask and find answers to the key questions that enable you to make better use of your time:
- What is important?
- What is urgent?
- What do I want to accomplish?
- What am I going to do today?
Unlike Scrum, My Personal Scrum has no rules to follow. My Personal Scrum consists of a few agreements to make with yourself and maybe one other person, so that you ask yourself important questions at regular intervals. If you miss a week, it's not the end of the world. If you find that certain aspects don't bring you value, it's OK not do them.I think of My Personal Scrum as kind a gravitational force - it exerts a gentle, attractive guidance that always pulls me back to doing the right thing. How does My Personal Scrum work?In a nutshell:
- You meet with your coach or manager once per week to review the last week and plan the upcoming week.
- You discuss what's important, what's urgent, and what you want to accomplish this week
- You visualize your goals and tasks with a Priorities Map
- You reserve time for important, but non-urgent goals.
- You plan your day
I have started asking people to help me validate the concept for a month. Learning continues!
If you think this is cool, feel free to try it out! I would love to discuss with you what works, what doesn’t, what can be left out or what is still needed! Comments, Please!
I’m giving two masterclasses at Agile Tour Kaunas on October 11 and 12 on Retrospectives and on Agile and Lean. Tickets for these agile workshops can be bought on the Agile Tour Lithuania courses webpage.
The two masterclasses are:
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
This is the first time that I’m giving my workshops in Lithuania. I’m grateful to Agile Lithuania for inviting me to their country.
The early bird price (till September 1st) for my masterclasses is 319 Eur (VAT not applicable). Regular price: is 379 Eur.
As an adviser, coach and trainer I helps organizations by deploying effective software development and management practices. I provide workshops and training sessions, public and private sessions. Here’s a list of my upcoming public sessions.
“I am no bird; and no net ensnares me: I am a free human being with an independent will.” ― Charlotte Brontë, Jane Eyre
A while back, I did an interview on how to build persona freedom from the inside out:
Freedom can mean a lot of things to different people. For me, in this interview, it was really about the freedom to live my values, choose better responses, and empower myself so that I don’t live somebody else’s story or play the blame game or take on a victim mindset.
The interview is raw, real, and unscripted.
Somehow, I think I avoided talking like a pirate, which is pretty good for me.
I try not to have a potty mouth, but it happens. I’m only human, and I grew up on the East coast
Anyway, I think if you haven’t heard this interview before, you will enjoy the insights and wisdom distilled.
It’s from the school of hard knocks, and I had to learn a lot of painful lessons.
The most painful lesson of all is that there is always more to learn.
Which means that rather than think of it as a finish line you are racing to, it’s about continuously growing your skills to meet your challenges.
You are an evolving being learning how to better respond to the challenges that your circumstances and environment throw your way, while you pursuit your dreams.
Always remember that nature favors the flexible.
Freedom is about building that flexibility, and it’s a muscle that gets stronger the more you practice it.
Whether it’s by standing up to bullies, or talking back to that little voice in your head that holds you back, or choosing to live the life you want to lead, not the life others want you to lead, etc.
The wonderful thing about your personal freedom is that the more you exercise it, the more you create personal victories and reference examples to draw from, so you actually build momentum.
It’s this momentum that can help you transform and transcend any area or aspect of your life to operate at a higher level.
Or, at least you can make it a choice vs. leave it to chance.
Take back your power, live life on your terms, and create the experience you want to create…with skill.
So much of life comes down to strategies, skills, and stories.
Use leadership moments and learning opportunities to create the stories that make you come alive.
That’s your freedom in action, and that’s how you live your freedom.
A few years ago, I was doing full-time consulting.
At one particular client, we were building a component based UI where pieces of the screen could be swapped in and out pretty quickly. This was all done through clean APIs that were message based and consistent across the components.
Each component was independent of the others.
None knew about the others, directly, but would communicate through in-process messages and a centralized communication mechanism.As I began to work on one particular screen, I noticed a problem.
We were laying out the software based on the old paper workflow, where there was information from a previous page that was needed on the current page.
In the software, however, it made more sense to move some of the current page’s components to the previous page, and some of the previous page’s components to the current one.
I thought through the reasoning and logic of the way the paper was laid out vs the changes I wanted in the software and it all made sense to me. It would significantly reduce the code size and complexity if we swapped these things around.I called my client and we talked about the changes I wanted to make.
He agreed on the reasons for the changes I wanted – it made sense and would be better. But he was concerned about timelines.
We were already running behind, and he didn’t want to continue pushing behind further. It was a valid concern – and it was his job to make sure we met the deadlines.
I expected the change to take up to 3 days as there were a lot of parts to move around and a lot of logic to change in order to make this work.
He reluctantly agreed and asked me to see if I could get it done faster than that.
I said I would try.15 minutes later, I told my client I was done.
The message based communication and component based architecture had given us far more freedom and flexibility in re-arranging and rebuilding the workflow than either of us had imagined.
I was able to take an estimated 3 day change and complete it in 15 minutes.
It was a great moment for both of us, to see that the work we had put into this was going to serve us well and create a system that would be far easier to maintain.
The benefits of messaging and decoupled components are many.But, the improvements found in messaging aren’t always that dramatic.
Whether in-memory or through the use of a messaging server like RabbitMQ, these patterns can provide significant architectural advantages. That client work was a prime example of how powerful these patterns can be.
Sometimes – especially when you’re first getting started – the benefits don’t seem to be there at all.
Sometimes you’ll sit back and look at what you built, and wonder why you spent so much time on it. You find yourself looking at something that should have been “simple”, and it became complex.The benefits are especially hard to see when first learning a technology.
Learning takes time and often creates more questions than answer.
I want to help answer those questions for you. I want to show you the benefit of messaging and good architectural practices.
I want to help you turn a 3 day estimate in to 15 minutes of work.
Join the mailing list, below, and over the next few weeks you’ll see how how these patterns can work for you.Tweet
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Leading development teams can be a challenging prospect. Balancing the needs of the business with those of your team requires a number of different skills and these situations are often very difficult to prepare for.
This panel session will provide a platform for a group of tech leads to come together and share their experiences, insights and advice around the topic of managing conflict and overcoming difficult moments within your teams.
Our panelists are all at various stages of their own leadership journeys and will be offering a range of perspectives and viewpoints to help you on your way.
The panelists shared their experiences around situations like:
- Having a tough conversation with a team member or customer;
- Sharing how they have dealt with overtime (weekends, later work);
- How they resolved a technical disagreement within a team; and
- Handling a particularly aggressive person, or being aggressively threatened;
The audience also threw in a few questions like:
- Dealing with office politics;
- Finding access to key influencers/stakeholders;
- Where you draw the line with a person on a team; and
- Dealing with a technical stakeholder who is too involved, because they seem to have too much time;
We also had some great sound bites in relation to the topics being discussed.
To deal with angry people:
Be the adult – Laura Paterson
Let them vent – Jon Barber
Managing stakeholders is hard, and you sometimes need to take a stance:
It’s easy to say no – Priya Samuel
People in teams need feedback to both strengthen confidence and improve effectiveness. However:
Frank feedback is really hard. Give the person a chance. – Mike Gardiner
Lastly when thinking about people and teams:
Have empathy. Pairing is scary & exhausting – Kornelis (Korny) Sietsma
I’d like to thank Amy Lynch for organising the panel, Laura Jenkins and Adriana Katrandzhieva for helping with the logistics, all the panelists who contributed their experiences and shared their stories (Priya Samuel, Kornelis (Korny) Sietsma, Mike Gardiner, Laura Paterson and Jon Barber) and all the people who turned up for the evening.
Have you ever had an idea haunt you night and day for years and years? An idea that won’t be deterred in spite of all the naysaying and fear you can muster? The kind of idea that sends your emotions running wild as though you’re the live bait in a zombie apocalypse movie?
Finally, after almost a decade of creating and delivering weird and wonderful concepts such as Agile Fairytales, Enterprise Gardening and even the first ever Choose-Your-Own-Adventure novel about Agile where you get to play the Agile Coach to save a failing Agile team in an online dating company, I’ve got myself a puppy.
Not the furry, lick-your-face-silly kind. Meet The School of Play, my new puppy of a startup, dedicated to promoting happier adulthood through lifelong play. The School of Play is a popup school where we inspire and enable adults to make their dreams come true by nurturing their inner chimp and developing their play intelligence through play adventures. Consider this your invite to play like you’ve never imagined… Not just for your survival. For your happiness and overall well-being. Play soon!
At a recent Agile Coach Camp I attended in June, a fellow participant said it best when he commented that as a software developer who had not really had an interest in people or relationships before, agile changed everything for him. He said Agile methods gave him a way to communicate with others, to trust them, and to understand how to work together to deliver excellent products.
What this gentleman was referring to, perhaps unknowingly, is one of the stages of team development. When an individual moves through stages of not trusting to trusting they are participating in an evolutionary process with a positive end result.
Daniela Moinau writes about this process in her article entitled, “High-performance Teams: Understanding Team Cohesiveness.”
She writes, “Once the storming stage is overcome the team is ready to establish open communications, stable positions and norms – the norming phase. Trust is finally gained, and “when the trust account is high, communication is easy, instant, and effective.” These are the first steps towards cohesiveness. Once cohesiveness is achieved, teams will move from norming to performing and subsequently to highly performing. ”
So while it may appear somewhat obvious that teams would trust one another, its not obvious to everyone. Each person carries their own unique history and their life experiences are of value. These experiences shaped who they are and what they have become. These experiences, whether pleasant or traumatic, shape a person’s ability to trust.
Agile methods to challenge teams to trust on a more profound level because of the nature of the values and principles which insist on it.
When a person, such as the software developer I mentioned in the first paragraph, overcomes his own internal patterns and learns to trust in a new way it leads to cohesiveness for him and his team. And this cohesiveness leads to high-performance.
As it turns out, trust is essential.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Some of you already know that one of my technical pursuits over the last few years has been to better understand and describe the way in which enterprises can apply Agile methods to building big and important systems, specifically “high assurance” systems that have an unacceptably high social or economic cost of failure. We see these systems in our everyday lives—automotive and aeronautic systems, defense systems, medical devices, systems that control our financial security.
In much of my first career, I worked primarily in the medical device industry, building computer-based systems for healthcare. In that environment, a bug could have catastrophic consequences. Fortunately, to the best of my knowledge, I didn’t leave any such bugs in the field and I eventually moved on to other pursuits. But my interest in super high quality software has remained. Now, as Lean-Agile development crosses the chasm to the enterprise, it’s a good time to understand and rethink how these methods can accelerate quality, as well as speed. In support of this, we built some additional hooks into SAFe 4.0.
My talk this week at Agile2016 was on this topic. The packed room was a good barometer that this is fast becoming a new focal point for many in Agile development, so I’m sharing the slides below for everyone interested:Download Building High Assurance Systems with SAFe 4.0
Anyone working with systems that are subject to regulation or industry compliance requirements, including Verification and Validation, should find this useful, especially if they are engaged in or considering a SAFe implementation.
I hope to turn this into a more detailed guidance article in the next few months, so your comments now on this topic are most welcome.
The idea to empathy mapping is to get to understand your users. Per the diagram below, you want to get an understanding of what your user thinks, says, feels, and does (though I have seen other examples that are slightly different than this). You would do this mapping for your main users for your product or the problem you're trying to solve.
To do this, you first want to identify the roles you are going to map. For each role, give them a name to personify it more. So don't call it Budget Approver, call her Laura. Draw out your map on a flipchart and draw a little sketch on Laura in the middle. Have the team talk a little about what Laura does, then have them start capturing these ideas on post-it notes and putting them on your flip chart. What you get is something like this:
Going through this exercise will help make some discoveries about what your users are going through. You can take this as a first step in identifying pain points; things you want to solve with your solution, but don't go into solutioning just yet. Take the observations and identify the themes that pop out. You can apply Affinity Diagraming for some structure if needed.
So now you are ready to get to insights. What does this really mean? Maybe it's time for the 5-Whys to help understand the situation. This is really the problem we're trying to solve. Now it's time to start discussing solutions.
As you get into development, don't throw out your maps. Keep them posted on the walls in your team room. As you are making decisions later in the project, they may help guide you.
A friend of mine recently asked some questions about developing a product, and creating the final deliverables.
He had been working for months, and had a deadline that he wasn’t sure about. But he needed to get the product done and launched or face serious financial difficulties.
In the discussion, I saw him constantly trying to design and build the perfect product as the first launch. And it struck me that he was going about this the wrong way.
While the product in question was not software, the techniques and processes that we often follow in software can easily be applied to what he was wanting to build.
So, how do you develop new products for a customer or a market and audience?Tweet
Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there. For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust. For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework. This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results.
To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behaviour of the team and all of the supporting roles (that includes their leadership). Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values.
Needless to say this can become an extremely complex challenge! To be absolutely clear, I’m not proposing there is a single formula or recipe that works, but I do believe certain criteria can dramatically improve your Scrum team’s chances of success. To that end here are 10 tips (plus a bonus) that may help you focus your efforts towards building a successful Scrum team and experience.
1. Right Number of Team Members
Currently the Scrum Guide recommends that Scrum teams will work best with three to nine people (not including the Scrum Master and Product Owner). Too few people on the team and you risk not having enough technical expertise and coverage of critical skills. Too many people on the team and you may become challenged to truly collaborate effectively. Remember, this is just a guideline and you may be successful with different numbers, you just need to be aware of the impacts and make sure the gaps are covered.
2. Appropriate Balance of Skills
Scrum teams really should be balanced and cross-functional. Having all of the necessary skills on the team for delivering a complete solution (not roles, but skills) will encourage and support end-to-end thinking all the way from design to implementation. This approach will result in a better solution and a superior customer experience, but it relies on whole team collaboration. Note this does not mean individual team members need to be fully cross-functional, but what is important is that all the critical skills are represented on the team and each team member contributes their domain expertise towards the collective strength.
3. Propensity for Engineering Technical Ability
For increased chances of success, a Scrum team should leverage technology and engineering practices whenever possible. Techniques, skills and tools that facilitate Agile approaches such as Continuous Integration, Automated Testing and Test Driven Development all make technical excellence, continuous improvement and truly being “Done” every Sprint a possible reality for a Scrum team.
4. High Team Member Allocation
Scrum team members should be allocated to as few different initiatives as realistically possible. The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be. In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most. This is true for any framework, but it is particularly emphasized with Agile ones. Note there is a slight but fundamental difference between being allocated to a team and being dedicated to a team – that is a topic for a future article.
5. Empowered and Knowledgeable Product Owner
Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in. They also need to be a strong negotiator and very capable at conducting business driven trade-offs. In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created. Without empowerment, knowledge, and vision in a Product Owner the team will struggle.
6. Equitable Scrum Master
Having a good process is only part of the equation. A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.
Remember that the Scrum Master has authority over the process but not over the team. As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working. In that regard a Scrum Master should understand and embrace the servant leader role. In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them.
7. Strong Executive Support
Leadership is the key to driving change and progress. Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.
Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures. And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.
8. Solid Partnership Commitment
There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking. The initiative must be an open, collaborative experience and there must be complete understanding and alignment by all parties in assuming the risks and rewards as well as sharing in the effort. This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative.
9. Reduced Team Dispersion
Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room. More simply stated, the greater the dispersion factor, the greater the challenge of collaboration. Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.
Although it is strongly recommended that teams be co-located, it is not mandatory to success. In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication. But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it.
10. Consistent Education and Coaching
To ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training. Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits. Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.
11. The Right Attitude!
Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs. Not just saying but living the belief there are no heroes or scapegoats. Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.
Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate.
At the end of the day your goal should not be to become Agile or Scrum savvy. Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers. These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention. Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.
For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach. To be clear, this is not easy to do but the rewards are well worth the effort. By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.
Can you think of other success factors that might help your Scrum team succeed? There are lots, so feel free to reach out and share them below.
Thanks to Photographer: Chris Potter for this awesome photo.
Sourced from stockmonkeys.com | Flickr PortfolioLearn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Formula for Building a Successful Scrum Experience appeared first on Agile Advice.
The book More Fearless Change by Mary Lynn Manns and Linda Rising provides ideas for driving change in organizations, using the format of patterns. This book is an new and extended version of their successful book Fearless Change.
I did an interview with Mary Lynn and Linda about how people are viewing change in organizations, the purpose of patterns and the benefits that organizations can get from using them, the new patterns that are described in More Fearless Change and the insights were added to the existing patterns, and their expectations about what the future will bring us in organizational change. You can read it on InfoQ: Q&A on the Book More Fearless Change. 15 Quotes from More Fearless Change
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Here’s a set of 15 quotes from the new patterns that have been added in More Fearless Change. I’m tweeting these quotes with #fearlesschange: No matter how great your new idea is and how well prepared you are, you are bound to meet some level of resistance Inspire people throughout the change initiative with a sense of optimism rather than fear When you feel discouraged, look for the bright spots among the challenges that surround you Displaying a warm smile and a willingness to be nice even when negativity surrounds you can go a long way To make progress toward your goal, state precisely what you will do as you take the next baby step To encourage adoption of a new idea, experiment with removing obstacles that might be standing in the way Change the environment in a way that will encourage people to adopt the new idea When you have a chance to introduce someone to your idea, you don’t want to stumble around for the right words to say Persuasion tactics must consider what people are logically thinking as well as what they are feeling By focusing on the future, individuals may be more motivated to let go of the past Your change initiative is a series of baby steps As you prepare to move forward, occasionally look for a quick and easy win that will have visible impact Stay in touch with your supporters—never assume that news of your progress is known across the organization Rumors need to be debunked before they take root and create significant concerns and anxieties during the change You can’t spend time and energy addressing every bit of resistance you meet Patterns can help you to drive change
If you want to truly change organizations, don’t try to plan it up front and don’t look for recipes. That won’t work (literally!). Patterns provide a useful format to convey ideas and to apply those ideas in a specific situation to do sustainable change.
Mary Lynn Manns and Linda Rising did a great job in this updated and extended version of Fearless Change. The experiences that they added to the existing patterns help you to get a deeper understanding, and the new patterns that they describe in this book are very valuable.
The patterns described in More Fearless Change help you to recognize situations and to come up with solutions for dealing with them. If you are dealing with change in organizations (and who isn’t nowadays) then I highly recommend to read this book and keep it close to you, as it will be useful at many times!
An opportunity to work at an extremely well-funded company that’s in the SaaS industry and they’re looking for a Scrum Manager who can drive results through high quality product delivery, decipher the issues in a team, and implement sustainable improvements. As a Scrum Manager, you will drive team efficiency and satisfaction through process improvements, communication clarity, and setting clear expectations on objectives and timelines.
You will be a critical member of their team. The ideal candidate will be someone who drives results and improves team efficiency, and is also highly resourceful in getting things done, and works well individually and collaboratively as a team. This person would also take on the following responsibilities:
– As we continue to grow internally and externally, the team will be looking to you to ensure that we uphold and drive sustainable productivity across the organization by achieving continuous improvements through team clarity, process improvements and influencing metrics.
– The Project management team is critical to the success of the organization as well as retail partners. You will be responsible for building team clarity and reducing stress from assumptions by being the guide of requirement clarity and executing on changes with all stakeholders.
– We have a tight knit group that places great emphasis on collaboration and teamwork. You will be responsible for empowering product owners and their respective teams to provide better development estimation through planning and execution based on proper timelines of product delivery.
– You will also be relied on to be the trusted leader who builds improvements to increase and maintain overall team satisfaction.
MUST HAVE SKILLS:
– Bachelor’s degree (Computer Science or Technical degree preferred), or strong software development background
– 3+ Years of solid Project Management experience; 2+ Years of Scrum experience preferred
– Knowledge of agile development best practices, project management tools
– Track record of implementing team process improvements
– CSM preferred but not required
– Ability to rationalize design decisions in a clear and objective manner
– Familiar with Process / Workflow analysis
– Effective in motivating teams and guiding them through impediments and/or conflict
– You need to be a great problem solver – we like to hire people who can think through problems and develop solutions quickly
– Our client is focused on results and are looking for someone who knows how to get the job done regardless of circumstance
Dress Code: Casual
Please send resumes directly to Bilal Tariq at firstname.lastname@example.orgLearn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Lately I’ve been appreciating the Top 100 Agile Websites compiled by Oikosofy.
Just out of curiosity, I thought I’d check out Number 100, just to see who was the lucky guy who wasn’t listed as number 101.
What I found was a delightfully surprising and pleasantly entertaining blog by a coach named Yves Hanoulle. One article which particularly caught my attention is called “Getting out of your comfort zone.”8 key points for coaches creating safety for their teams
- Getting out of your comfort zone is important for personal improvement
- When you do experiements as a coach to learn people about this, people might see things differently, because of their earlier experiences.
- Give people a safe environment so they can learn to push their boundaries.
- People need to feel safe to move out of their comfort zone.
- The Safety Zone is bigger then Comfort Zone.
- Stepping out of your Comfort zone increases the size of Safety Zone.
- Staying to long in your Comfort Zone decreases your safe zone.
- Safety zone is perceived.
His reflections after a training seminar on the topic really made a lot of sense to me.
Basically, an agile team is striving to create a Safe Zone for themselves and their team-mates so people will take risks and move out of their comfort zone. In order to do this, they are or become really comfortable with that uneasy state of being uncomfortable.
It’s as though it is no longer uncomfortable to be uncomfortable.
When an agile team moves out of its Comfort Zone together and everyone feels safe and supported, the end result is the type of team described in the Agile Manifesto. It’s the type of team companies really get excited about. It’s the type of team people love to work with and in doing so they may find they love their work more than ever.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Are Agile Teams Just More Comfortable Being Uncomfortable? appeared first on Agile Advice.
A new bundle of books with agile practices and tips has been released on Leanpub. Buy these books with a 40% discount!
The bundle includes six great books from eleven authors, helping you to make your agile journey easier to travel, more successful, and fun!
- With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.
- A Toolbox for the Agile Coach: 96 Visualization Examples showing how great teams visualize their work.
- The tools and techniques provided in the Forming Agile Teams workbook offer an alternative-proven way to add more structure, transparency and visibility to the work that you do when Forming Agile Teams, by combining visual explanations with techniques and tips to support Scrum Masters crucial role within the organization.
- The Scrum Master Workbook Part 1 provides 15 weeks of accelerated learning. It teaches you ways to deal with conflict, bugs, interruptions, meetings and many more topics.
- Patterns of Agile Journeys shares stories and patterns to help you recognize situations you may find yourself in on your own journey. Use the tips in this book to reinforce or counteract the patterns you see.
- The book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Together these books provide many useful tips and practices for your agile journey. Buy them for $40,77 (regular price is $67,95).
There’s also the Agile Retrospectives Books Bundle with six great books that will make your agile retrospectives rock, and the Valuable Agile Retrospectives – All Languages Bundle which contains all language editions of my successful book Getting Value out of Agile Retrospectives.