Category: team
I've written a lot about mistakes we made and the parts of Scrum we didn't follow, to our detriment. We've got a late, still as yet unlaunched project, reduced credibility and lowered morale. And yet, even with all this going against us we still have one big thing going for us: an incredibly strong team. In this part of My First Agile Project I'm going to address this issue of teams and the importance of strong teams in Agile projects.
Read on for 5 important issues teams should look for. Some are good things, some are bad. But I believe we have a strong team and hopefully our lessons can provide some insight into building a strong Agile team.
Bookmark/Search this post with:
When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.
Bookmark/Search this post with:
Scrum is a team empowerment framework. Scrum is an agile product management process that is based on the clear separation of what's and how's -
Product Owner is responsible for what's, the development team is responsible for how's. This clear separation puts big bet on the team's ability to self-organize and figure out what exactly process and practices are best for it.
In my practice I've seen teams that gelled successfully, communicated with their customers frequently and were indeed able to self organize to whatever was needed for the frequent delivery of good software wanted by the customers. However, I also experienced teams that are struggling despite the credit from management. Their Product Owner (or Product Owner teams) were able to fix the product priorities for a sprint, they did explicitly tell that they want less features and more quality, they did allow their teams to work on architecture as much as they needed and still the quality wasn't on par with the expectations. The testers tested according to the scripts (and not according to what the user might want do), POs often were able to find obvious bugs during the sprint review demos, etc. Despite all the trust credit these teams just didn't self-organize.
Bookmark/Search this post with:
picture courtesy of xurble@FlickrI've talked with my friend recently and he complained about his team leader (actually he was explaining me why his team leader sucks). It's not about her personality or attitude but my friend's biggest complaint was questions his team leader asks him e.g.:
- Is everything OK for you?
Well... How can you answer this question. Is she asking about my private life, my development environment, my current assignments? What answer does she expect? If almost everything is OK for me but I have some ideas how to improve team's performance should I answer "Yes", "Yes, but..." or "No"? This is a wrong question IMHO - it shows lack of respect because team leader doesn't really care about the answer, it's like "How are you?".
If you are Team/Project Lead and you lead development team you should read this post and get to know engineer's point of view.
Bookmark/Search this post with:
Every Sprint,
the Team commits to deliver some functionality to the Product Owner. A
lot can happen during the course of a Sprint. How does the Team know how much it can commit, and how does the Scrum Master ensure that the Team actually deliver what it committed?
Bookmark/Search this post with:
In the absence of market facts, he who owns the compiler wins. © Steve Johnson
If you are on the customer side of a project (for example, being a Scrum Product Owner or a person above him) you might have experienced a situation, when you ask team for building features A, B and maybe C, and the build C, D and a bit of B, "because they thought D was more important for the user".
Theory
Scrum theory on the customer side is simple. Formulate your requirements in a list, team commits to what it can, implements the committed items during a sprint and in the end you accept or reject what they managed to come up with.
Ok, being a good product owner you don't separate yourself that much from the core team. You regularly groom the product backlog together with the team and during the iteration help the team understand what exactly you want, but the process still revolves around listing requirements and accepting/rejecting their implementation.
Bookmark/Search this post with:
Teams. What are they and how do they work? They're groups of people working together collaboratively toward a common goal. They're held together by strong bonds of commitment, trust, and loyalty. The stronger the bonds, the better the teams. But sometimes, there's a hidden glue that nobody ever realizes is there. Sometimes, that hidden glue is a single person on the team that really keeps it driving ahead. And most of the time, nobody notices who that person is until they're not there.
Bookmark/Search this post with:
One of the key benefits of agile and Scrum is the growth and maturing of the teams that work together. The longer a team works together, the more it learns about itself and its members. The team learns what works well for them and what doesn't and they use this information to adapt their practices. This learning is central to the continuous improvement of practices that drive the engine of great agile teams.
However, a problem exists in many organizations (especially consulting organizations) that may denigrate the effectiveness of this core agile practice. I'm talking about short duration development teams. If you've worked in the consulting world, you've been there before. Teams are assembled in a mix-n-match fashion to tackle specific contract jobs. Many of these jobs are short term, just a few months in duration. Then, the team is disassembled, put back into the "resource pool" and reassigned to other jobs with new teams.
Bookmark/Search this post with:
A Google search on the text "Ask and Thou Shall Receive" got me a few different references to Bible chapters, including Matthew 7:6-8, Luke 11:9-10 and John 16:24. It seems that the disciples were never shy of asking when they wanted something, and I cannot blame them.
Asking people for things you want really works!
Children Asking
There's a saying in my language (Dutch): "Wie vraagt wordt overgeslagen." It roughly translates to "Those who ask will be skipped". It is often used to get children te keep quiet when they're asking for sweets or presents. But my grandmother, a religious person herself, has fought against this idea. Several times she said to us: "Children that never ask, will not get what they want." She actually might have been referring to "Ask and Thou Shall Receive", either consciously or not.
Bookmark/Search this post with:
I've been thinking a lot about the collocation of agile development teams (or any development team for that matter). Some people argue that collocated team members are essential to successful software development while others argue that it doesn't make any difference. The more I think about it, and the more we operate with geographically dispersed teams, the more I'm starting to believe that collocation matters.
Currently, our team is spread out between Ft. Collins, CO, and Orlando and Jacksonville, FL. While things have not gone terribly wrong having dispersed team members, I have noticed a difference in communications. The difference is that in the Ft. Collins office (and I'm sure in Orlando and Jacksonville), there is a lot of informal communication that occurs amongst collocated team members. You know, the kind of discussions that happen spontaneously. When these happen, a lot of project information gets passed between team members that doesn't get transmitted to other remote team members. There is no malicious intent to not communicate. It's just that the impromptu discussions don't usually inspire anyone to dial in to a teleconference number and all that...precisely because they are impromptu.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle