Friday, October 14, 2011

Fifth session at Agile Management (Scrum Master) course at University of Washington

Today's agenda was:
- Definition of done
- Agile Estimating (still continued in the next session)

Definition of Done:
Helps us build the thing right versus the acceptance criteria which helps us build the right thing

There can be various artifacts to call a story or sprint or release done.
For example, we call a story done if unit tests passed or acceptance tests passed.
we can all a sprint done if bugs found during sprint are resolved and release notes are updated.
A release is done when integration tests on deployment build pass and release notes are delivered.

Then we did one more fun exercise to define few artifacts to call various levels done in building a travel web site. For example, travel operators need to follow some govt. compliance so that becomes part of the definition of done.

Agile Estimating:
Different people provide different estimates for the same task. That happens mostly because of different assumptions.

A little effort at understanding requirements and estimating, helps a lot. But a lot of effort would help only a little more.

People are naturally good at comparing things. So there are relative sizing methods. We did an exercise to give some points to various breeds of dogs. Mostly these numbers were from fibonacci sequence. We used smartphone apps for "planning poker" for expressing our estimate of dog point. If there are differences of opinions in estimation, person with far estimate would express why does he think so? And then vote is taken again to reach an agreement eventually.

Estimation is very important topic and is gladly continued.

We are also going to have some guest speakers from industry, so more fun is lined up.

Saturday, October 8, 2011

Third & Fourth session at Agile Management (Scrum Master) course at University of Washington

Oh yes - third & fourth. It was a long Saturday : 9 to 4 :)
Today's session with Stein Dolan, was mostly oriented toward Product Owner (PO)'s role in Scrum, user stories development in large part.

Traditional models like waterfall define what, to reach "low" unknowns' level. At the end, they start implementation part - "How".
Agile models like Scrum define "what" and "how" pretty much together to achieve a decreasing curve, due to simultaneous reactions.

User Stories: are requirement / deliverable for a sprint (or initially production backlog).
Card - Token representing requirement that reflects priority & cost (effort estimate)
Conversation - mostly verbal but possible supplemental documentation can be presented
Confirmation - Acceptance of what needs to be done and called be done.

As a << user >>
I want to << goal >>
so that << value >>
Where, user - end user of the product
            goal - feature
            value - why feature is important or gives

For example, As a user I would like my search results to be paginated so that I do not have to scroll through a long list of items

A nice question came up with this: How 500 user stories are better than 500 pages of documentation?
My take is that user stories are very very short, and provider better management possibilities of prioritization and partial releases.

We went through a series of exercises:
  1. Prepare a vision statement for given project definition
    (where we want to build a web site to connect various organizations like soccer teams, PTA, church to build communities)
  2. Prepare list of user roles you can think of
    (again following the same above short project definition)
  3. Preapre 3 releases and their features
    (on how do you want to execute and release some features on the given project)
  4. Prepare user stories
    (Write actual user stories for the features defined so far)
  5. Prepare acceptance criteria for user stories
    (Write sort of functional tests to define acceptance requirement for the particular user stories)
Epic user stories : are the ones not decomposed to valuable, estimable, sized & testable ones.
Theme: is a collection of related user stories
Epic is a theme when split into smaller stories

Wow, that was a lot in a day. But, lunch buffet was good at Bombay Grill (Indian Restaurant) in University of Washington Seattle campus.

These are just notes that I am taking on my blog, but I want to revisit major topics as I learn more in ongoing sessions.


Thursday, October 6, 2011

Second session at Agile Management (Scrum Master) course at University of Washington

Today's instructor was Stein Dolan, from Microsofot.

We learned that Agile is all about Values & Principles. There are defined tools and processes to implement Agile.

Agile Manifesto
We value -
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Should every sprint duration be equal?
Yes - it helps a lot. We can get better data over time which can help determine team's velocity for a given time duration.
Also, team resource changes also should happen at beginning of new sprints only to assure team and sprint efficiency.

We were asked about our goal to join the class.
I have done scrum in the past. I did that with self-learning to begin with, and I liked the visibility Burn-down charts represented.
Then I worked on a project at Microsoft, where we implemented Scrum with the tool - Tackle. That team was rocking. Team members have already estimated the work item in hours. Every day, team would enter hours they worked on any work item, and if they want to re-estimate. So, at the end of the day, we can easily see if everything is on track. I have seen this work, and so much appreciate the visibility. For me - this kind of visibility is primary reason to do scrum. But, I want to know more details on how to build these processes.

We learned about the roles in the Scrum.
Product Owner (PO) - is the person(s) who is responsible for all inputs(requirements) and outputs(releases).
Scrum Master - is the person who facilitates sprint and stand up meetings. He is supposed to make blocking issues and team collaboration smoother.
Team - is responsible to work estimates and implementation.

Product owner focuses on Vision, Product and Releases.
Team focuses on Day, Sprint and Releases.

We are going to perform some exercise on a given project definition. It will fun.

Thursday, September 29, 2011

First session at Agile Management (Scrum Master) course at University of Washington

Yesterday was my first session of Agile Project Management course in University of Washington. I joined this course to get a larger perspective of project management practice, more views and some ideas on agile estimation process.

This was my first time at UoW Seattle campus, and I was having hard time finding building for commuter services and my course. Even with a buffer of 45 minutes when starting from Kirkland, I reached late by 30 minutes to my class! Bummer!

Anyway, after a rocky start - it was a good session. The instructors are Mitch Lacey (ex-MSFT) and James Newkirk(MSFT). It was mostly an overview of Scrum, and why scrum?

Few important notes from the session.

  • Product Owner(PO) - keeps track of all user stories / requirements / backlog
  • PO will request what he wants to see delivered in the next sprint.
  • Scrum team would ask questions about these requirements, before any estimation takes place.
  • Scrum team will discuss how to approach these requirements in the upcoming sprint, and provide estimates based on that. This is the key - implementing team will provide the estimates. PO has to trust the team and their estimates. Since sprint time is already determined, now PO and team have to figure out final work items that can be delivered in this sprint.
  • Test / QA is always part of the sprint. It's significantly important part of calling the sprint deliverable are done.
  • Waterfall model takes Features in, to provide cost and estimate. Agile model takes cost and schedule in, to provide features in a value driven approach.

First session was good, looking forward to next session - next Wednesday.

Friday, September 23, 2011

My thoughts on future computing after Windows 8 preview

First impression of Windows 8 developer preview is definitely - Bravo! Yes - a job well done. API - great, Cloud integration - great.

But even before I had any glimpse into what will windows 8 look like, I started to believe that platforms do not matter any more. What matters is an app with good user experience and cloud.

Users want to use their data with consistent and good user interface. Apple created few device categories few years back. There will be many more devices and integrations in the near future.

I would say MS is just catching up on App bandwagon. Apple did it because they wanted to give great experience over smaller screens. Everything is not about facebook and weather on desktops though. Mostly people use desktops to get things done. I start to think, was there even a need to catch up? I don't have that answer, but I'm eager to see what time unfolds.

HTML 5 is offering much richer and consistent experience on every platform than previous versions. When Apple created app bandwagon, HTML 5 was not at so good stage. HTML 5 can provide geo-location and offline or local data kind of features, which were non-existent to implement in a browser at that time. Audio, video, animations can be played in standards based manner to support multiple platforms. So, HTML 5 kills many reasons to develop and support separate app for every existent platform when we have many of them.

Microsoft Office is the cash cow for Microsoft. And I think competitor is not going to be another office suite, but it will be apps and cloud providers like Evernote and recently got enterprise order from P&G. So, no more need for Share point and office documents. People who use salesforce and other cloud applications like that, are very less likely to use any Office suite. Every processing is moving to custom apps. So, in a sense, it may have been a right move to make a platform or so to speak - ecosystem for apps on windows. Enterprises may not have lot of love for such ecosystem, because they need to act private and custom. Consumers may have love for a consistent experience ecosystem, but no single company is likely to win the position as Microsoft have enjoyed over the years. Users will make their choices and most companies will have their chance.

New Metro style apps can be installed only from the app store. One can not download it from anywhere else. That's a new experience for windows users and partners. Let's see how is it welcomed by both communities.

I am a .NET developer and love the framework and tools. I'm just afraid to live without them :) But when it comes to windows, I am really tide to it only because of these tools.

Wednesday, September 21, 2011

New blog

I am happy to finally re-activate my blog and blogging! I have been thinking to do so for a long time, but it wasn't just happening.
I realized just recently that my domain came to pendingDelete status after somebody took over it in the past. So, I was closely watching it to be available again and I was able to acquire back on Sept 20th.

I immediately thought I must start my blogging again, to put this domain to better use :)

To those who are thinking what is pendingDelete ?? Well, I owned domain in the past. But since I was not using it any more I let it go. Then I wanted it back but it was acquired by somebody else for parking (web site full of ads - not so useful to public). Recently, that guy decided to let this domain go so he must have let it expire without paying renewal. Then domain goes to pending delete state after few days. There is few days gap, so that if the current owner forgot to renew, he can still do it with additional fee, but can gain privilege to keep ownership. Once pending delete period is over, domain is available for anybody to register. That's when I jumped in to acquire it.

OK, back to blogging. I plan to blog about my thoughts on mostly this fast moving technology, since a lot goes through my mind while reading about technological advances.