We had a great turnout for the first in our Transitioning to Agile Webinar series, and many questions came in that we were unable to answer. Below you will find my answers to the questions that we weren’t able to get to on during the Webinar.
Q: Can Scrum succeed without XP engineering practices? Won’t the rate of progress drop to a crawl if you’re trying to deploy every two weeks without taking advantage of the XP practices related to quality and automation?
Possibly, but I can’t imagine trying to practice Scrum without at least many XP practices. Scrum and XP complement each other so wonderfully practicing one without the other wouldn’t be advisable. If you could find practices that were non-XP, but had the same relentless focus on quality and automation you would be fine. The important pieces are the quality and automation here, not XP specifically.
Q: How do you determine the proper time frame for the sprint? Agile is new to our organization, and we hear from our developers that 2 weeks is not enough time to complete anything of substance.
This would usually indicate to me that Backlog Items are probably not broken down small enough, this is a very common problem when organizations are first adopting Scrum. In my experience the act of splitting Backlog Items or Epics small enough is among the most difficult things in Agile, while simultaneously being one of the most important. This is one area where an experienced agile coach can prove invaluable.
One additional thing to keep in mind is that not every item on the Backlog has to be in User Story format. Many items make no sense in User Story format, so don’t try to make them a User Story. The story is an invaluable tool for gaining understanding of the work that is going to be done.
Alternatively this could indicate that automation isn’t pervasive enough in the organization, that the team is not yet in the correct mindset of doing “The simplest thing that could possibly work”, or that the team is not engaged in a healthy Estimation process on the items (indicating a possible need to schedule regular Backlog Grooming meetings).
Q: how should we manage design, build, test in the same sprint? without design build cannot happen,
The Backlog Items should have enough Design work already done on them that the team can get started with the work when they commit to completing the item in the sprint. In practice I often see the Designer working with the Product Owner and possibly Stakeholders/Customers on backlog items that are scheduled in the next sprint. This doesn’t mean that continuing design work is out of the question during the sprint.
Frequently a Backlog Item cannot be understood without design work already complete.
Q: We are in the process of transitioning to Agile. The biggest complaint we are getting is that “this takes too much time”. I don’t see how we are going to be more productive. Is there a good response for this?
I would ask What takes too much time. If it is meetings, then you will want to look at ensuring that you have solid Scrum Masters to help facilitate Timeboxes. Remember that Standups that go over 15 minutes are NOT Standups. [tweet this] If the statement is coming from people who have been assigned to be Product Owners or Scrum Masters I would ask you if they had those roles tacked on to a job they already do?
An all too common failure point in Agile transitions is that individuals are not given proper training or the undivided attention it takes to be effective Product Owners and Scrum Masters. These are truly full time jobs, and entirely new roles in business. Saying “we can’t afford full time Scrum Masters or Product Owners” is like saying “we can’t afford full time Accountants or Developers”.
Q: What is the difference between ScrumWorks and TeamForge? [tweet this]
ScrumWorks is very narrowly focused on Agile Project management, and it meets that function very well. It does not however touch on Agile Engineering practices, or anything outside of Agile Project management. TeamForge on the other hand does, with a broad variety of integrations to tools like Hudson/Jenkins, GIT, Subversion, Eclipse, etc. Teamforge is also process agnostic, so that it is often a better choice for organizations that are in a long term process of adopting Agile. Teamforge is also an ALM tool used extensively by large banking institutions, governments, and complex industries such as medical development.
Q: Does one person set all the ROI? How do you get the scale to be accurate across a number of people?
In ScrumWorks the ROI value is a calculation based on a value input to indicate the Benefit of Inclusion in the Product. Another value that indicates the Penalty of Omission from the product. These two values are added together to give us a Business Weight. The Release Business Value is calculated by comparing the Business Weight of this item to the Business Weight of all other items in this particular Release (a Release may indicate a real release, a period of time, or any other block of work we like).
The ROI is calculated by taking this Release Business Value and factoring in the Effort Estimate, or difficulty of this item in comparison to other items within the Release.
Because different groups can put in the Benefit, Penalty, and of course Effort we can calculate ROI based on the input from 3 distinct groups. For more information I would suggest looking in our documentation on Earned Business Value: http://www.danube.com/docs/scrumworks/pro/latest/userguide.html#earnedbusinessvalue
Q: Any recommendations on test suites?
I do not at this time, I believe any recommendation would vary depending on the type of development you are doing. I also have personally not been involved in choosing a test suite for a project, so I don’t feel qualified to give a recommendation. That said I think that there is one major priority when choosing such a tool: Speed. Anything that is too cumbersome or takes too long to return the outcome of your tests to the developers should be discarded in favor of something faster.
Q: What are the standard lengths (in hours) for different type of Scrum meetings?
This depends based on the complexity of work and duration of sprints typically. The only hard rule I personally enforce is that Standup meetings should not go over 15 minutes. As a general guideline I typically see most meetings set at 1 to 2 hours. Scrum Masters tend to spend a good deal of time determining what amount of time a meeting may need to be to maximize its effectiveness.
Keep in mind that Timeboxing is an effective way to force a certain level of detail. If a meeting to estimate 10 items is scheduled for 1 hour that forces the team to spend no more than 6 minutes in discussion and estimation for each item. This can be a valuable tool to reduce over-analysis.
Q: How we can correlate Story Points Vs Actual Hours in Agile Estimations?
Agile estimation is all about Relative Estimation, the Value is in separating this estimation process from Time.
Later (after we observe how many of these Estimation units we complete on average per sprint) the Product owner may map these points back to time. This mapping is easily accomplished. For example, if the team completes 50 story points a Sprint, and the Sprint is 2 weeks, the team completes 5 story points per day. (50 points divided by 10 days)
Always keep in mind that this calculation will change a little bit every sprint, and we should Never consider the idea that 5 Story Points = 1 day when we are in the process of Estimation.
Q: how you deal with teams with different level of skill, for example some are good at java program and some are less experience, how do make use of those people in the team with less experience? would agile help in this area?
Scrum doesn’t speak to this, but XP does. In particular the practice of Pair Programming is an invaluable way of bringing the less experienced team members up to the level of the experienced teams. I don’t know the details of your situation, but you might want to look into carefully shuffling the teams to involve more of a mix of skill levels. Shuffling teams is never something to take lightly, but if done right it may prove invaluable for your organization.
I would suggest looking into Extreme Programming: http://www.extremeprogramming.org/ for more information on Pair Programming.
Interestingly (to me at least) the practice of bringing less experienced team members to a level of mastery in their job is very motivating. There is an interesting book by a man named Dan Pink called Drive that goes into details about why. I would suggest watching this RSAnimate video summarizing the book: http://www.youtube.com/watch?v=u6XAPnuFjJc
Q: Can we use ScrumWorks to build teams? people with different skill for projects?
Certainly, ScrumWorks allows you to do anything with teams that you like. I highly recommend sticking to the Scrum guidelines for Team structure, but ScrumWorks isn’t going to stop you from configuring teams in any way you find necessary.
Q: Considering that a team should be small, should all the team members also be of an equal expertise level?
In a perfect world, certainly yes. In reality? This is impossible. No two humans are ever of an equal expertise level. In my experience every Scrum team has a mix of expertise levels, and skillsets.
Q: How do manage measuring story points vs hours when doing hourly billiable rates? Typically an estimate/cost would be provided up front to a client.
Until you have established stable teams and have some sort of stable Velocity (i.e. how many Effort Units do we complete on average per sprint) this cannot be done in an Agile fashion. When an organization is first adopting agile this estimate is usually going to be provided in exactly the same way as it was before the Agile adoption.
Once we have some observed progress we can use the method I outlined a few questions back. For example, if the team completes 50 story points a Sprint, and the Sprint is 2 weeks, the team completes 5 story points per day. 50 points divided by 10 days. When our team is stable, has been together for enough time to work smoothly, and has a relentless focus on quality, this calculation of 5 story points per day can become surprisingly reliable. That calculation can then be used for providing the up-front cost estimate (after the team has had a look at the project and given a rough estimate of its relative difficulty).
That wraps it up for the questions from the Headlight Reporting Webinar, but not for all of our questions. Check back again for more Q&A answers.