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 allocatedto a team and being dedicated to a team – that is a topic for a future article.
“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.”
Can you believe there is an actual disorder which prevents people from seeing their own limits? It makes them over-cofindent to do things and yet under-skilled to achieve them. If you have a person with a disorder like this on your team, it can lead to disaster.
But you likely are not aware of what exactly is going on. Not until it’s too late.
You can read for yourself the nature of this condition and how a Scrum Master can help a person who perpetually under-estimates or over-estimates their capacities.
What I like so much about this article is that despite the challenges of working with someone who is largely unaware of what they don’t know, is that the author offers encouragement to Scrum Masters.
Basically, a scrum team turns no one away. We are all capable of some degree of contributing. This article shows that the more a Scrum Master knows the individual team members and the collective capacity of the whole team, the better everyone can be!
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.
He suggests using a virtual board and if anyone has had experience with this please leave a comment below. It would be great to read how this has been used with success.
With or without this virtual board, I really think he is on to something. With tact and wisdom, virtual meetings through online forums such as Google Hangouts or Skype can really give the impression of being face-to-face with people.
It provides more visual body-language cues which are missing in phone calls and this is bound to help keep communication among a distributed team much stronger.
This article, posted on Oikosofy’s blog, gives a pretty good introduction into the way things were in manufacturing and the way things are now. In “Agile-Manager — What is an Agile Manager?” he goes back to the time of FORD to explain how things have progressed.
It shows that not only have agile methods changed the way things are made, but they have also changed the corporate environment which houses the teams who make the products.
He also address how so many businesses now offer services and how that effects development.
Mishkin has proposed three sessions for the Toronto Agile Community 2016 conference. Part of the evaluation of the sessions to determine if they will be accepted for the conference includes a voting system. Please take a few moments of your time to check out my session proposals, and “like” them if you think they deserve it… and of course, please check out the other proposed sessions and support other potential presenters! Here are direct links to his three sessions:
At the Best Western Lamplighter’s Inn on June 24, BERTEIG had a booth set up for the annual south west chapter of the PMI Symposium. In the relaxed, resort-like setting, surrounded by palm trees and tropical plants, project managers from across Ontario came together to learn through a series of workshops and seminars about the latest developments in the world of PMI.
I chatted with Director of Business Development, Nima Honarmandan about the experience. Here are a few of the highlights he shared.
Nima said the talk was inspiring and had real motivational depth.
Nima’s experience with talking with others in the business area is that unlike previous years, everyone he spoke with had in one way, shape or form had come into contact with agile. He said this is a new trend which shows how much progress agile has made over the years.
Nima’s message to the inspired participants, those managers from across the region who were feeling ready to embrace change, was that “We can help you change!”
It was a well attended event and we look forward to it again next year.
What is agile exactly? How do we practice it? What does it look like to be an agile product owner? What is an agile team?
One of the qualities I’ve come to admire the most about agile teams and agile ambassadors is this continuous state of learning which everyone agrees to be in.
It seems as though “being agile” gives us permission to sometimes know an answer and sometimes not to. It gives us permission to sometimes understand a situation and have a solution and sometimes not to. Agile methods have a built-in “Reality Check” which is so refreshing.
By openly communicating often in retrospectives and by making work and backlog visible the process is taken out of the abstract and into the concrete. Agile seems to put everyone on the same page ~ even if people are coming at agile from very different angles.
Recently I posted a question to the 2500+ members of the Facebook Scrum group, asking for good recommendations for meaningful resources.
Dozens of individuals receive training to become Certified Scrum Product Owners at our public learning events in Toronto, Ontario.
What is a Product Owner? And how do they create a product vision in alignment with the team they work with? Xi Zeng, over at 3 Agile Guys blog, has some ideas worth sharing.
Here is an excerpt from his article on product vision.
How can a product vision help you?
A project always has a predefined scope and goals, therefore defining a vision for a project is in most of the cases not really necessary. A product has usually a much bigger scope and a longer life cycle, so it’s important to create a product vision in advance in order to:
help the business define requirements
be able to evaluate the value of the project
simplify the communication among the organisation (or with clients)
act as project’s compass
support the prioritization and decision-making in projects
The vision should consider the long term life cycle of the product and should not be easily reachable. Define even a vision that is almost impossible to reach. All short term goals should be clear defined and measurable, e.g. what is the next step in the project, next valuable goal, how to prioritize work items in backlog, etc. But the vision represents the long term future, it should stay ambitious. Just like when you’re hiking on the mountains, you can see the rocks under your feet, you know their size and form, you can touch them and even pick them up. But you can only see roughly where is the top of the mountain. While hiking, reaching the top of the mountain is our vision.
I think there is a lot of value in what Xi writes and it is worth exploring in greater depth.
On the blog “Fragile” the author writes about the human side of Agile. The author, who does not name themself anywhere on the blog, criticizes the agile movement for not giving more time to the issue around management.
Here are some of the key arguments:
not enough care is taken over the distinction between project and line management
almost all agile implementation failures could be traced back to management’s reluctance or failure to engage
practical guidance is needed for an agile team leader to describe how they might incorporate these ideas into their role.
The author also notes that an anecdote they wrote was included in a recent book. It basically describes a way to make the most of an environment even if management is not providing funding or space to support agile implementation.
Here is the antidote:
It may not always be possible to create the perfect working environment, however it is important to make the most of what is available. My team were looking to map their work flow using a white board and sticky notes. Unfortunately we were situated in the middle of an open plan office without access to walls, nor did we have the necessary space for a for a free standing white board. In the end we bought a roll of white board sheeting and applied it to a nearby structural pillar. Work items flowed from top to bottom and space was tight, but it served our purpose and is still in use years later.
I am wondering if others have had similar experiences of getting resistance from management but still being able to make their situation work out anyways. Please share your story in the comments section below.
Although I was first introduced to OpenAgile in 2013, Scrum and Kanban are relatively new to me this year. While not working in a tech-based department which uses these methods, I am interested in learning as much as possible about each system. I found her explanation and chart very helpful.
Here is a quote and chart she features in the article:
“Both Scrum and Kanban are unique and emphasize on more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and the commonality in both is to keep delivering quality product.”
Advantages of Scrum
Advantages of Kanban
Improved credibility with clients
Focus on Continuous Delivery
High Product Quality
Increased productivity and quality
Team members reach sustainable pace
Team members ability to focus
Allows client to change priorities and requirements quickly