My colleagues and I from BusinessWeek gave a presentation last week covering our agile planning and development process and ended with an intro to SCRUM by @silviogalea. Roughly the same time, @jurgenappelo posted an excellent, easy to follow slideshare on The Zen of SCRUM 1.0. Here are my top takeaways (no particular order) from these presentations plus some of my own thoughts:
1) Organizations looking to 'go agile' should start small by picking a project, getting a team, and assigning the key SCRUM roles. Counter intuitive - we recommend picking the most important or high risk project - to help reinforce the organizational changes needed and the required interaction between IT and Business.
2) Make sure someone on your team has experience practicing agile. Ideally the product owner or the Scrum Master. Look for a coach if you need some help.
3) Good reason to go agile - "requirements change" and there's "too much time wasted on junk". Also see my post on why stories work where requirements documents fail.
4) Need help on story writing? Stories are not exactly use cases or tasks. They must answer "As a -who- I would like to -what- so that -result achieve-". Also see writing good user stories,
5) Daily SCRUM "Commitment and accountability, say what you do, do what you say, whole world is invited" - I would add "transparency".
6) Contrast the sprint retrospective with the classic 'postmortem meeting'. Think about it. Your technologists meet after each sprint and talk about process improvement.
7) Let the team estimate in 'ideal person days' or 'story points'. It doesn't matter what's used when you start, but it is important to get the team started on some metrics.
8) Don't expect to have things perfect when you start; a perfect product owners, scrum master, or even a backlog. Every organization I know practicing agile has to fit the roles and practice to the business, organizational, and technological dynamics.
9) Work board and stickies are important because these tools help the team prioritize and communicate efficiently. But balance these with technological tools even if they are simple spreadsheets. The tools help with transparency, metrics, and developing a history.
10) SCRUM is sometimes reduced and oversimplified to project management of a fixed cost, fixed time line, variable scope project. Don't make this mistake. You're leaving out the key social dynamics of the process that make for agile success stories.
Monday, February 23, 2009
Thursday, February 12, 2009
How does your SaaS vendor respond to the scalability question?
Ask some CTO’s about how their product scales and they’ll whip out a logical diagram showing you redundant networks, redundant firewalls, load balancers, clustered application servers, redundant databases, and SAN storage. If you’re lucky they’ll tell you about their software stack and then throw in a bit about their software development life cycle.
If this is how your SaaS vendor responds to scalability without going into some operational specifics, then beware.
If you are a very early adopter of a SaaS vendor, then you’ll want to look at infrastructure. You’ll definitely want to be evaluating their leadership and their business plan.
But let’s assume for a second that you’re not one of the first ten customers. Scalability for a SaaS vendor has at least the following areas:
If this is how your SaaS vendor responds to scalability without going into some operational specifics, then beware.
If you are a very early adopter of a SaaS vendor, then you’ll want to look at infrastructure. You’ll definitely want to be evaluating their leadership and their business plan.
But let’s assume for a second that you’re not one of the first ten customers. Scalability for a SaaS vendor has at least the following areas:
- Software platform – How often do they put out new releases of core software? How is it rolled out to customers – in one shot or in waves? How do they handle the QA of these rollouts – and specifically, do you need to participate in this testing.
- How do they monitor their systems for service level and capacity issues?
- How do they manage network operations? How is staffed? How fast do they respond and recover from issues? Can you see their issue log?
- How are customer specific implementations managed in their software repository? Beware of the runoffs!
- How are new features prioritized? How do they involve customers in the prioritization?
Sunday, February 08, 2009
Agile Product Owners in the Enterprise
I really like this post Agile Product Owner and Agile Product Manager in the Enterprise that highlights the organizational issue of trying to staff agile product owners in the enterprise's technology organization. Staffed this way, product owners are bound to contend with product managers because their responsibilities somewhat overlap. On the other hand, trying to get a product manager to take on the responsibilities of an agile product owner often does not work because of the time commitments (good product owners spend a significant part of their time - 66%? - with the tech organization) and because of the needed technical skills.
The post does a good job going into the details and so they are not worth repeating in this post, but here is my two cents on a solution. Most technology departments have project managers who often are (and should be in my opinion) technical and are also good business analysts. These project managers should be spending a good deal of their time understanding the business requirements and overseeing the schedule and deliverables of the technology team. Project managers that have these capabilities can take on the role and responsibility of product owner. What's more, a good product manager should embrace this structure as it frees him/her up from getting in the weeds on implementation and allows them to focus more on product strategy. The product manager may object to assigning a project manager a role titled 'product owner', but hopefully a good org chart and description of responsibilities can alleviate this tension.
In this structure the product owner / project manager becomes more of the story curator than the story writer. I'll elaborate in another post. Looking forward to Dean Leffingwell's solution to this key issue.
The post does a good job going into the details and so they are not worth repeating in this post, but here is my two cents on a solution. Most technology departments have project managers who often are (and should be in my opinion) technical and are also good business analysts. These project managers should be spending a good deal of their time understanding the business requirements and overseeing the schedule and deliverables of the technology team. Project managers that have these capabilities can take on the role and responsibility of product owner. What's more, a good product manager should embrace this structure as it frees him/her up from getting in the weeds on implementation and allows them to focus more on product strategy. The product manager may object to assigning a project manager a role titled 'product owner', but hopefully a good org chart and description of responsibilities can alleviate this tension.
In this structure the product owner / project manager becomes more of the story curator than the story writer. I'll elaborate in another post. Looking forward to Dean Leffingwell's solution to this key issue.
Tuesday, February 03, 2009
Evaluating SaaS Vendors – Understanding Business Models and Profitability
For those of you who don’t know, I was CTO of a SaaS vendor a number of years ago. In addition to building a SaaS platform (back then in 1996 when we started we were an ASP – application service provider), we acquired and merged with a number of other SaaS companies. Part of my job was to evaluate the viability of the SaaS company's technology platform and operations. So I have a few things to say and tips for those of you in a SaaS company or evaluating one.
Mind you that I am, in general, pro SaaS. As I said last week Don't be afraid of SaaS but Diligence is Required.
First and foremost, you need to find ways to evaluate their business model . Some vendors like Google (apps...) Salesforce and Quickbase have achieved operational scale or are profitable. But many SaaS vendors that we look at are startups or growing companies. If you can’t get their profitability, there are some quick questions that can help you evaluate their profitability. Consider the VERY simple model:
(Num Customers) * (Average Price Normalized By Year) – (# employees) * (fully loaded cost/employee)
Again, obviously a huge hand wave, but many SaaS vendors will feed you information on customers and employees – if not – beware! Show them that you can do this calculation during their sales call and they may be more willing to disclose more details on their profitability.
Why is this important? Because, quite frankly, many SaaS vendors underestimate how far they are away from both financial and operational profitability. For example, many SaaS vendors still believe that their core business will be the foundation for other, more profitable businesses. Now that SaaS vendor’s Board and investors may buy into those future businesses, but you as the customer are taking on the risk. These future businesses may never materialize and that their core business (for the product you are buying) may never reach profitability.
If it appears that the vendor needs a large number of new customers to achieve profitability, better dive deeper to learn how they will close the gap.
Mind you that I am, in general, pro SaaS. As I said last week Don't be afraid of SaaS but Diligence is Required.
First and foremost, you need to find ways to evaluate their business model . Some vendors like Google (apps...) Salesforce and Quickbase have achieved operational scale or are profitable. But many SaaS vendors that we look at are startups or growing companies. If you can’t get their profitability, there are some quick questions that can help you evaluate their profitability. Consider the VERY simple model:
(Num Customers) * (Average Price Normalized By Year) – (# employees) * (fully loaded cost/employee)
Again, obviously a huge hand wave, but many SaaS vendors will feed you information on customers and employees – if not – beware! Show them that you can do this calculation during their sales call and they may be more willing to disclose more details on their profitability.
Why is this important? Because, quite frankly, many SaaS vendors underestimate how far they are away from both financial and operational profitability. For example, many SaaS vendors still believe that their core business will be the foundation for other, more profitable businesses. Now that SaaS vendor’s Board and investors may buy into those future businesses, but you as the customer are taking on the risk. These future businesses may never materialize and that their core business (for the product you are buying) may never reach profitability.
If it appears that the vendor needs a large number of new customers to achieve profitability, better dive deeper to learn how they will close the gap.
Subscribe to:
Posts (Atom)