Top Ten Thoughts for SCRUM Newbies

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.
continue reading "Top Ten Thoughts for SCRUM Newbies"

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:
  • 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?
The point is, scaling is really about scaling for more customers and all service level dimensions, not just infrastructure.
continue reading "How does your SaaS vendor respond to the scalability question?"

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.
continue reading "Agile Product Owners in the Enterprise"

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.
continue reading "Evaluating SaaS Vendors – Understanding Business Models and Profitability"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.