This 3-day training covers 3 Agile methods: ScrumMaster (the most popular Agile method), OpenAgile (the most widely applicable Agile method), and Kanban (a method that can be used together with other Agile methods).
Learn more at:http://www.berteigconsulting.com/ScrumCSMOpenAgileKanbanJuly2011MarkhamTorontoOntarioCanada
Wow – thanks to everyone who links here, reads this blog and tweets about it! You’ve helped this blog score at #22 in the top 200 agile blogs list!!!
Just a quick note to let people know that there are spots available in the seminar we are delivering on June 8-10 in Toronto, Ontario. This seminar includes Level 1 of Scrum: Certified ScrumMaster & Level 2 of OpenAgile: Certified OpenAgile Team Member plus Kanban.
This week I met someone while on a personal trip who is in the software business. His company writes software for a very specialized vertical and from everything he said to me, they are an innovative company and do all the right things including empowering their teams to self-organize, regular training for the staff and generally a great working atmosphere.
The company has still been struggling with getting their product to be “deeper” (his word) for their client base.
I was again reminded of a post of mine from a while ago encouraging or providing cross-training or at least some knowledge to bridge the barriers between the software group and the hardware group (link at the bottom of this post). In my environment, I’ve been fortunate to have a network admin sitting with our team. It has prevented many potential problems.
Having been involved in the infrastructure part of IT as well as development, I knew of at least a few products almost immediately that could make his product more compelling to his customers.
To my surprise, I found out his company was only looking at software improvements to their application. He told me how they are continually developing new features but are not considering running on any new platforms.
I mentioned a few technology (hardware) improvements he could consider and I know that by the time he gets home this weekend, he will have taken a look and passed the information on to his team. These improvements could immediately add significant customer retention and usability to his product.
From our discussion, it was also evident that his team would enjoy the challenge of some new platforms to keep encouraged about the future. I’m sure that by the time he reads this, he’ll have some of these technologies in hand :->
As Agile practitioners, it seems, we are so focused on improving our software development cycle, our specific development tasks, our daily or hourly builds, our programming skills, and how we create story points, sometimes we seem to lose track of the big picture… What is the customer going to use it on? This should be fundamental to every developer’s thought processes.
Think to yourself, ”HEY, should we be seeing if our software could run on some of the new technologies out there such as Microsoft Surface, some of the new Wireless Devices, or even benefit somehow from new 3D technologies coming out”?
I like to think that developers who are empowered with information about hardware can think of all kinds of ways to use it.
If you’re on an Agile Team or managing one, ask to learn something about the hardware in your environments. Consider some “slack” in your Sprint or some work breaks in your Cycle to allow team members to learn something about new Infrastructure or Hardware products.
Think for a moment if your company is writing software for the Web, the power of a deep understanding of how a load balancer actually works, or my personal favorite, the .NET Cache.
Let it be the teams’ choice of which products though. That will give the best motivation and most likely will be the most enjoyment for everyone.
It will broaden your horizons and perhaps give your team ideas you never knew could even be possible.
If we always just wait for a Marketing Person or Product Owner to come up with interesting ideas, where’s the fun in that?
References :
My previous post – Infrastructure Knowledge for Developers
3D example – Sony 360Degree viewer prototype
Microsoft Surface – Microsoft Surface Web Site
Slack – A good article about slack in XP by James Shore
Sprint – Scrum Alliance
Cycle – Open Agile
Colin Geissler, has written a brief summary of some of the differences and similarities between OpenAgile and Scrum.
I am regularly asked for examples of where Agile Practices could be used that are not related to software development.
I recently came across this video and just had to share the link to it.
The company encourages all team members to participate, keeps things time-boxed and makes appropriate use of subject matter experts.
It’s awesome to see what can be done in 5 days.
http://www.youtube.com/watch?v=M66ZU2PCIcM
From time to time I am happy to list positions that are available in organizations that are becoming agile or already are agile. For what it’s worth, this position was described verbally to me as being much like a Scrum Product Owner. Here is the position information:
Project Manager at zu
Closing date: Monday, May 30, 2011
Our new Agile PM will manage full life cycle website/application development projects using the Agile methodology, work closely with our strategists, designers and development team and other stakeholders to manage requirements, scope, milestones, timelines and budget.
As an Agile Project Manager at zu, you enjoy working with other talented people and succeed when we deliver a project worthy of being called “zu-made” to a client. You live to under promise and over deliver.
You have a passion for Agile Software Development. You are eager to work with and share your experiences with a team transitioning to Agile. The thought of finding new ways to adapt Agile to an existing team excites you.
As a team leader, you inject enthusiasm into the combined zu-client team, adding transparency and candidness to communication in all directions. Using your natural ability to develop rapport with all types of people, you liaise regularly with the client and team, keeping progress on track and delivering on expectations.
You are excited by the idea of creating things that have never existed before, that learning and teaching are everyday occurrences, you don’t mind dressing funny from time to time, or bringing a dish to the potluck.
If you have the required experience, pride yourself on being extremely well organized, have a magnetic personality, sense of humor and are eager to be a part of an evolving company, then what are you waiting for? Drop us a line!
Background
Post secondary education in business or technical field
Minimum three years related work experience
Knowledge and experience with Agile software development, processes and methodology
Ability to work effectively on concurrent, multiple tasks and projects
Ability to effectively manage priorities in an ever-changing environment
Outstanding leadership and teamwork skills
Clear and concise documentation skills; you can write mean user story
Strong verbal and written communication skills
Responsibilities
Document, learn and support all aspects of projects: scope, risk, schedule, budget, quality and communication
Manage client expectations and co-ordinate and deliver progress updates to ensure the successful delivery of projects on time and on budget
Manage all project related requests with the client
Ability to guide and direct production teams to keep them on budget and schedule while continually inspiring them to innovate and provide the best solutions for our clients
Work with development teams on a daily basis to clarify requirements and to provide feedback
Facilitate developing user stories based on requirements
Prioritize and prepare product backlog and facilitate estimation meetings for strategists, designers and developers
Communicate project status with stakeholders and gather feedback for review and implementation
For more information about zu, head to our website: www.zu.com/live/careers.
Wow! The 3rd and last day of the Scrum Gathering in Seattle was epic! I am tired and thrilled to have participated in such a great day, and such a great conference. Thank you to all who made this happen.
Un-Conference Sessions Using Open Space Technology
This was something that I had some reservations about. What does this mean that we all decide what will happen and how it takes shape? However, this was, by-far, one of the most interesting and engaging parts of the entire conference. Here are the 4 principles of Open Space: (1) The right people show up (2) Whatever happens is the only thing that could (3) It starts when it starts (4) It’s over when it’s over.
There is one law to Open Space: If you are not learning or contributing where you are, find a place when you can learn or contribute.
And there are two roles in Open Space: (1) Bumblebees – these people bounce around to other sessions and add new ideas. (2) Butterflies – these people sit somewhere and look beautiful, and may not attend sessions. I guess that I was neither a bumblebee or butterfly, like most of the participants.
So we were encouraged to come up with topics that we wanted to facilitate and/or learn about and pick a time slot and location. This happened quite naturally – which was added to the marketplace for the participants to choose which sessions they would like to attend and contribute to.
Open Space - one participant adding his session to the wall
My 1st Session – Team Estimation Game by Chris Sims
This is the first time that I had the privilege of seeing Chris in action. He is a dynamic and very effective teacher and facilitator. The game is another method for teams to estimate effort for User Stories (in Scrum) or Value Drivers (in OpenAgile) or whatever you use for your particular Agile method.
He had us form small teams to estimate effort on consuming various types of fruit (which were on cards) including: grapes, orange, durian, pineapple, apple, blueberries, pomegranate, and coconut.
Step One: This was carried out by each person taking turns and doing one of two things: (1) placing a new card on the wall or (2) changing the position of one card. This was pretty easy and allowed us to have conversations on what we meant when we did an action.
Step Two: Then the team had to add numbers (also on cards) as a way to categorize the effort that would be done. Now each person had three options: (1) place a new card number, (2) moving a single card on the wall, or (3) passing which means that you agree with what is currently on the wall.
Chris Sims (on left) showing the Team Estimation Game
My 2nd Session – How to Launch a Team by Roger Brown
Roger showed us a few things to keep in mind when helping to launch an Agile team (usually done by him in a 3 day training on-site).
A ScrumMaster or Coach has certain things to do during the various stages of a team’s development: (1) in Forming, he needs to be directive and tell the team what needs to get done, (2) in Storming, he needs to focus on conflict resolution for the team, (3) in Norming, he needs be a facilitator and observe and then offer ways to improve, and (4) in Performing, he either needs to work on organizational obstacles or move on to another team.
Roger explained how the constant sprint length for a team helps it to get into a rhythm and get data such as the team’s velocity (the speed at which it gets things done). He also offered a great tool for people to use called the Market of Skills which comes from Lyssa Adkin’s book “Coaching Agile Teams”. Other things to use include a team working agreement, team vision, and a definition of done. He said that he likes to spin up 2 or more teams at a time to that they can learn from each other.
<
Notes from Roger Brown - How to Launch a Team
My 3rd Session – Collaborative Work Spaces by Skip Angel
Skip made this session very collaborative and got us to add own challenges and questions to a flip chart page and then get us to share how we would solve each others challenges.
Insights included: share visual stories to help the team see benefits, promote outcomes, tools to use for collaboration. Some tools and useful sites: http://sococo.com, http://onemoreagileblog.com, http://cocoo.com, and http://agileadvice.com !
Skip Angel on Collaborative Work Spaces
Here is the format that he shared for a User Story: As a (type of user) I want (something) so that (value). Enter the things within the parentheses ( ).
Here are the 4 techniques for splitting stories that he shared: (1) Conjunctions / Connectors – words such as if, and, but or even commas. (2) Generic Words – eg. activities which could be broken into sports, dancing, and board games. (3) Acceptance Criteria – which is a list of pass/fail items that if agreed the story is done. (4) Time-line – which are steps of sequence to get something done.
Met Chris Sims
I spoke for a few minutes with Chris. We talked about David Parker who used to work at Berteig Consulting (where I work) and now works at Agile Learning Labs (where Chris works). Chris had nothing but praise for David!
Sharing by Participants on the entire Scrum Gathering
Each person shared something that they like or enjoyed about the conference. I shared three things: (1) the humility of the Certified Scrum Trainers (CST) and the Certified Scrum Coaches (CSC) to share with all of us their knowledge and their ears, (2) the wisdom of everyone at the conference, and (3) the amount of smiles and laughter that was the reality of all of us who attended.
Closing Keynote by Joe Justice and WikiSpeed
Joe gave an epic keynote on his team that built a car that gets 100+ MPG. It was amazing and super inspiring! I don’t even know what to say about it. He and his distributed, collaborative, and highly Agile team of volunteers did incredible things. I hope to buy one of their cars when I done with my current car. It is that good!
Joe Justice showing the WikiSpeed Car
Final Thoughts on the Scrum Gathering in Seattle
So this was my first Scrum Gathering and it was amazing. From the people to the food to sessions to the Open Space to the Certified Scrum Trainers and Certified Scrum Coaches to the people who it made run so well – Fantastic! I hope to attend another Scrum Gathering in the near future. I already plan on attending the one in London, England in October 2011.
Warm regards,
Paul Heidema
So after another day at the Scrum Gathering in Seattle, I am tired! Not just from the sessions, conversations, and the learning but also from waking up in a time zone that is not my own. I live near Toronto which is 3 hours earlier than Seattle. I am slowly getting used to it. Especially that today is a sunny day.
Mastering the Basics of Leadership Storytelling by Steve Denning
Steve Denning showed us how the art of storytelling can uplift and help people to see why a change is needed. He got all of us to do an exercise (1) What’s the problem? (2) What would the world look like if the problem was fixed? (3) Tell the story of the person who doesn’t want the change.
When I did the exercise I though of a client that saw that there was value in using Scrum and Agile but was unable to see the need for organization to adopt them or the urgency to make the change as soon as possible.
Steve also spoke about 3 good ways to get peoples attention: (1) share something unexpected (2) share something relevant to the audience (3) and make it negative. I understand what he is saying but I am more motivated by a positive outlook instead of scaring people by harsh realities. To each his own I guess.
Steve also shared the 7 rules for performing storytelling: (1) maintain eye contact (2) maintain open body stance (3) don’t hide behind notes and podiums (4) use gestures using your whole body (5) dare to pause! (6) practice, practice, practice and (7) be there, be present by planting feet on the ground.
Steve Denning - Leadership Storytelling
I will co-train with Carlton Nettleton
I met again with Carlton Nettleton who is a Certified Scrum Trainer (CST) out of San Diego. I am excited that will be co-training a Certified ScrumMaster (CSM) training seminar sometime in Toronto during the month of August or September. So… keep those dates open! He is very interesting guy and I have no doubt that he is a great teacher and trainer.
I also met Mike Cohn
If you don’t know who Mike Cohn, I recommend searching for him on the net right now! He is a well-known author, trainer and coach in the Agile and Scrum world. We spoke about our experiences and some of our learnings. I also shared how Mishkin Berteig and I have used OpenAgile to help C-level managers and upper managers to be an Agile team so that the teams on the ground see the example by the leadership. He is open and kind man.
Agile Coach Self-Assessment: Where Do You Stand on Competencies by Lyssa Adkins
This is by far my favourite session that I attended in the first 2 days of the 3 day conference. She got all 30 participants to stand and be players in the session. This is what we need more of in conferences that are in the Scrum and Agile world.
Lyssa Adkins - Coaching Competencies
She placed 8 phrases on the ground that were quadrants coming from a centre point that represented parts of an Agile coach. The 8 phrases were: (1) mentoring, (2) technical mastery, (3) transformation mastery, (4) teaching, (5) facilitating, (6) Agile Lean practitioner, (7) business mastery and (8) coaching. We had to do a few things. First, figure which section we were strongest in. Second, choose which section which we wanted to be in. Third, decide which will be our sections to work on (we had to choose 3 in priority) and then choose on section that we would let go.
I also met Vibhu Srinivasan who is one of the newest CSTs (just become one on Sunday). He lives in India and is an extremely nice guy. We were asked to work with one person at the end of the session with Lyssa and then check in with each other to see what progress we made.
Second day was great! Tomorrow we get to be part of the “un-conference” sessions where the participants choose what is important and then prioritize that stuff and work through it together. It should be great!
Warm regards,
Paul Heidema
I have now just returned from Day 1 of the Scrum Gathering in Seattle. This is my first Scrum Gathering and it is turning out to be great!
Participants at the Scrum Gathering in Seattle
This is what I did throughout the day and some take-aways and learnings that I have gathered:
The Business Case for Agile: What Every Executive Needs to Know with speaker John Rudd
- there are now fewer constraints, with more variables in our world
- example of horse races, move bets to the horses in front
- use examples of failures in your organization to encourage the change
- benefits and ROI model
- waterfall: 15%
- agile: 30%
- agile with reduced scope: 50%
- People that I met in the session:
- Bill Rosner from Capital Group who is on a Scrum team in California
- James Kauffman who is the ScrumMaster near Seattle
Do We Have a Good Coach or a Bad Coach? with speaker Alan Atlas
- all about learning: good or bad
- results for a coach: direct (eg. launching a Scrum team), indirect (eg. less bugs produced)
- the SKERT framework: Skills, Knowledge, Environment, Results, Type of coach
- get feedback on coach throughout the year
the SKERT framework by Alan Atlas
30 Minute Chat with Alan Atlas
The Scrum Alliance set up this great thing: Scrum To Go. A participant can sign up for a private session with an experience Scrum coach, I believe that all of them were Certified Scrum Coaches (CSC). So I signed up to speak with Alan Atlas. He was very kind and knowledgeable. I asked him about becoming a Certified Scrum Trainer (CST) and many questions about helping teams to use Agile and Scrum. He offered three things to help when team members are not buying-in or becoming empowered on the Scrum team. (1) Team members to convince themselves of its usefulness and validity. (2) Peer pressure from other team members to become active participants. (3) Cheap coaching tricks such as putting those against Scrum in charge (you are now the ScrumMaster) or getting those team members to research something and share it with the team. He said that we don’t like to do bad work, so they will try to get the task done.
Scrum To Go: coaching sessions
Met Other Great People
Talked with Roger Brown (a CST) about the Certified Scrum Coach (CSC) process and how it has evolved. I also asked him about co-training with him for me to become a Certified Scrum Trainer (CST). I also met Vernon Stinebaker (a CST) who lives in China and was trained by Mishkin Berteig, my colleague, many years back. I had the honour of meeting Lyssa Adkins (a CST) in person for the first time. I spoke with Lyssa, emailed back and forth, and I was part of her Agile Coaching Circle which took place over conference calls and emails. She is a wonderful person who is extremely motivated to work with coaches who, in her words, are the change catalysts in organizations. She introduced me to Carlton Nettleton (a CST) who I spoke with about co-training with him to become a Certified Scrum Trainer (CST).
Overall it was a great day. I look forward to learning more and meeting more great people. My take away for the day: Scrum people just like helping!
Warm regards,
Paul Heidema
Now I am in Vancouver only one step away from Seattle, which is the location for the Scrum Gathering. I will go tonight to the hotel and register. I am excited to see the layout and look into the sessions.
I just read that the 3rd day of this 3 day conference has many sessions called “un-conference” open sessions. I like that this is a creative way to hold sessions which are normally setup with a speaker and a bunch of learners.
I hope that we will experience what we train. An environment where individuals interact to learn things, instead of a bunch people that have cups needed to filled up by an expert.
More to come!
Warm regards,
Paul Heidema
I, Paul Heidema, am currently waiting at the Toronto airport for my flight to Vancouver and then to Seattle where I will be attending the Scrum Gathering. This will be my first Scrum Gathering, so I am excited, curious and a little nervous. What will it be like? Will I enjoy myself? What talks should I attend? Will I feel lonely? What is expected of me? These are just a few questions that I have rolling around in my mind.
Usually when I attend a conference, Agile or not I am with others that are familiar with the movement of the event. Not this time. However, my wife Laila is coming for the trip which makes it that much more enjoyable even though she is not attending the conference.
I hope to meet many trainers, consultants, people new to Scrum and all kinds of unique and wonderful people.
I am also in the process of applying to become a Certified Scrum Trainer (CST). I hope to meet other CSTs and learn from there experience.
I will post more throughout the event.
Warm regards,
Paul Heidema
Just a quick note to let people know that there are spots available in the seminar we are delivering on May 25-27 in Edmonton, Alberta. This seminar includes Level 1 of Scrum: Certified ScrumMaster & Level 2 of OpenAgile: Certified OpenAgile Team Member plus Kanban.Details can be found here.
In an Agile culture, it is considered rude to refer to people as “resources”. People are not fungible – you cannot just take any old developer and plug them into any old project. Skills, personalities, likes, talents, potential all are so dynamic and unique for each individual person. So any management theory (including traditional project management) that treats people as “resources” like oil, gold or computers, is making an unjust simplification at the expense of the people working in the organization.
Yet organizations need to be able to plan where to spend money, and certainly the people working in an organization are often one of the largest costs. From a financial perspective, from a business perspective, it makes sense to somehow treat people costs in the same way as other operational costs… and this often leads to dehumanizing people to the point of treating them like resources.
So how can these legitimate organizational needs for budgeting mesh with the equally legitimate approach of Agile to treating people as unique actors be merged? It is actually quite simple, but the ramifications are deep: treat TEAMS as resources. Teams become the fundamental building blocks of an organization. Teams move from project to project or program to program or operation to operation. There is still a need to support the individuals in an organization, but it is done in the context of teams.
An Agile team is cross-functional, but also constantly learning. Individuals on the team learn skills based on their own interest, but also based on the needs of the team for redundancy, parallelism, and expansion of capacity to take on new, more challenging work. Cross-functional teams can more easily (and more sanely) be compared for their value to the organization by looking at things such as their ability to produce finished product/services, their flexibility in serving the needs of the organization, and the quality/consistency of the work they produce. Teams can compete in a healthy way by striving for excellence in delivering value to the organization, whereas often competition between individuals can be quite unhealthy.
From a budget perspective, teams are easy to manage: each team has a fully loaded cost based on salaries, space, equipment, etc. The cost is (or can be) relatively stable or grow predictably, and can still be handled operationally. As well, unlike individuals, it is much easier to treat a whole team as a fungible unit: you feed work to teams based on their availability rather than based on a detailed analysis of their skills/capacities/allocations.
In Agile organizations, teams are resources, people are not.
As many who have tried know, an Agile Transformation in a company is not always an easy process. Although most people at first are keen to participate in the idea of “changing” the company culture and working environment to “something better”, many do not realize how much work it can actually be.
For some of you, you will be fortunate enough to be in an “Agile” environment already.
Perhaps you are using OpenAgile, or Scrum. You may be using a unique variation such as the Pomodoro technique.
For those of you that are new to the idea of Agile Processes, no matter what your flavor of framework or tool, there is something you will not be able to avoid. Politics.
There is no getting around this. Agile transformations are about change in an organization and not just change in one small section of the company.
Although many Agile teams start as “pilot projects”, even in such small situations, the effect on the departments or culture at the “edges” of even the smallest teams can start to cause ripple effects in an organization.
The first secret is to acknowledge and accept that this is going to happen. Life will be easier for you this way. The job of any one assisting with an Agile implementation is to provide honest information and advice to help those who will be directly or indirectly impacted.
Don’t think you will be able to just hide in development and not be noticed. Be prepared with slides, web site links, and open to talking about your processes and ideas with anyone who wants to know. You must be transparent and open about what you are trying to accomplish.
OpenAgile for instance is defined as a “Learning System” because it deals with the realities that no one can work in a bubble and that more than just the “development team” needs to be involved in Agile practices for them to work. The entire organization will be learning with you.
Scrum has a well defined set of guidelines to follow in regards to the development process and is ideal for new software development projects.
Lean is a more gentle approach to changing an organization in small, progressive steps.
Don’t kid yourself. No matter how small the changes will be, there will be resistance from someone, somewhere, from where you least expected it.
The important thing to remember is what your goals are. The goal of the framework is an open and honest discussion between all those involved in your organization and general culture shift to a blameless, team based shift in thinking.
However, what is the real goal here? Happy customers, happy employees, and therefore, a profitable, progressive organization. You must remember the purpose is not to make teams, but to make a good product for the customer. Sometimes, you may find it hard to remember.
I recently read The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials) by Jon R. Katzenbach and Douglas K. Smith. It clearly explains, with examples, how an organization with the courage to change their culture can really benefit from an overall culture shift towards Consultatative Decision-Making and team work based approaches.
Consistently, companies who simply “say” they have teams under-perform those that actually “just have teams”. One type of company has them by edict or decree, and the other just has them because the culture is that way. The ones with the naturally team based cultures do much better financially. Hmm..interesting.
Change is usually started by some kind of need to change because things aren’t working out “the old way”.
Buggy software, unhappy customers, late releases…Whatever the pain, the results are always a “desire to change”.
Those who have the courage to admit they need to change, should be applauded. If you are new to Agile and reading this, please pat yourselves on the back for having the courage to learn more.
Now, it should be “easy” to stay on the path if you keep at it. The act of Starting is the first big step. Congratulations!
One thing you will find as you proceed is a continual list of “it won’t work because of this”, “it won’t work because of that”. But, hey, you’re not selling snake oil here. You’re talking about people in an organization taking control of their work and working together for the best solution possible for the company and it’s customers. Keep it simple.
Agile processes are just that … Processes.. They are not there to replace common sense. Agile is not a silver bullet to cure a company’s culture. That part of things is still a human thing and will take time. Please don’t think of Agile as a cure for a bad culture. It is simply a way to help the culture to change.
To me at least, what is important is a consistent message. I believe this is the key to helping an organization to be an Agile one.
Let’s take the Daily Scrum (for Scrum teams). I worked with a company where the Daily Scrum was considered a waste of time and a nuisance for those involved (at first).
The daily scrum is a quick recap of where everyone on the team is. For more information about the Daily Scrum, just do a quick search. There is an abundance of information about it. Try the Scrum Alliance for definitive information.
At this company, the owners and senior managers considered the scrum to be a nuisance. The senior developer of the team found it to be a hassle. Then, after a few weeks of doing daily scrums, any team member could be asked by someone passing in the hall what was going on and that person could easily tell them what the status of the project was. There are many other advantages to the scrum, but that’s not what this article is about. Maybe another time.
When I first started at this company, there was a weekly “developer meeting” which at first was the only way to exchange information. It was generally 2 hours/week. The team was now doing daily scrums and having small “mini-chats” (for lack of a better word) occasionally when needed. Team members knew from the Scrums what was going on and who needed help with what and then self-organized to solve their problems and arranged “mini-chats” as needed to help each other out.
The “weekly 2 hour developer meeting” just became a thing of the past. The team just stopped having them.
Waiting until the end of the week was far too cumbersome for something they could get from a 10 minute scrum and occasional ”mini-chats”. The team had unknowingly switched into a mode where they practiced regular consultative decision-making and regular re-assessment of their situation.
Then a remarkable thing happened.
One day, I was in a meeting, and the senior developer who at first was reluctant, banged on the window of the board room I was sitting in for me to come to the 10:00 AM Scrum which was 2 minutes away. I excused myself from the meeting and returned approx. 13 minutes later. The owner of the company said “Why do you do those daily meetings. They are such a waste of time. You have that big Developer Meeting every Friday”.
My response was “I’m sorry, but we don’t need to waste our time with that big 2 hour meeting every Friday anymore… We haven’t needed them for a few cycles now”.
What a remarkable experience! In one quick step, and after considerable pain, not only was it evident that the senior developer embraced the Agile Scrum Meeting, but also the owner who was previously unsure suddenly came to realize that the team was far more effective than he knew and he hadn’t even noticed the shift.
The developer culture had changed to a more team based one without his knowing. All team members knew what was happening and Expected to be kept in the loop from now on.
The key is, keep doing it ! Be consistent. If you’ve implemented a standard Agile practice, stick with it.
Be realistic though. There will be people who consider it to be “stupid” and there will be people who don’t want to participate. As a new implementor, NEVER humiliate anyone in the process. Simply encourage open discussion and ask everyone to contribute. At first, people will be shy or nervous about this. Over time, it will be the norm to participate.
The point is that as time passes, people and things change. The new processes will become Common Place and not so foreign and people will start to appreciate the fact their opinions are important and they have an impact on the bottom line of the company and the customer. This is what drives people to be happy and succeed.
Then, with a bit of luck and perseverance, someone in a different department will say “Hey, I think that seems like a good idea. Tell me more”. “Do you think this Agile stuff might work in sales?” might be the kind of question you suddenly receive. Do yourself a favor and be prepared for this with some links to a few Agile Methodologies at-hand!
This is your opportunity to introduce the new “culture” into a different part of the company.
With a bit of patience, others will come on board. It will be a great experience for you once you have others helping out.
The day will come when someone will try and remove an Agile process somewhere in the organization and team members will lobby for their cause. This is the day you will know… I have succeeded with step 1… Getting started !
From here forward, it’s just a matter of consistently trying to improve things one cycle or iteration at a time, and watching things get better for the customers, employees, and of course, the stakeholders.
If I can give one last bit of advice. Please do a bit of research before implementing something. Ideally, you want the teams to come up with how to do their daily work, not yourself. Let any process be the team’s process, not yours. Of course, if you have a new team to Agile, you will need to help them get started.
Consider your job as one of just guidance and coaching. That will work the best.
Review your environment carefully before deciding about methodology and do some reading or contact a coach about the differences. Should you be using Scrum, OpenAgile, XP, Lean, etc? Think about it carefully. They have different levels of organizational change and are for different applications. Use Wisely. :->
If you’re courageous enough and have an experienced Agile team, why not ask the team which Agile Methodology will work best for them? I personally enjoy learning something new all the time. :->
Mike Caspar, CSM, OpenAgile Certificate Holder, ATPL
http://mike-caspar.blogspot.com
References :