Thursday, December 12, 2013

In Scrum, Is the PO a toaster?

Well, look up the Scrum Guide:


Saturday, May 4, 2013

Agile North Galilee meetup #1 - Minimal Viable Meetup

So we've finally had the first Agile North Galilee meetup today!


Let's start with applying some hard Scrum Values:
Openness- I'll be dead frank here - there were 3 attendees. Yes, 3.
And now that we're over that embarrasing number, let's see what the rest of the world minus 3 missed out on...


Focus - For myself I was pretty focused on having the meetup happen, this was good because.. well.. it finally happened :) For the next meet I'd like to focus on both volume (more people) and concrete value-adding content.


Courage - I had absolutely no idea what was going to happen in the meetup, nor how many people would come. I guess neither did any of the other attendees. And we came and met nontheless. that's courage to expect the unexpected for ya.

Respect - Ok I can't help being sarcastic here... remember 3 people?
Nontheless I do respect the fact that people did not come - we took a chance holding the meetup on a Friday morning - extremely nonorthodox. Also quite honestly I did not put much effort into making sure more people would come - for me this was an experiment, a sprint-zero or minimal-viable-meetup so to speak, the goal was to practice a meetup and give ourselves a chance to learn in preperation towards the next meetup which should be bigger and value-adding to the attendees. More on that later.

Commitment - The attendees drove quite long distances to come, and like I mentioned it was a Friday morning - so kudos to their commitment! it is not given for granted. I see this commitment rooted in the North Gallee's practitioners to work in general - we have people commuting long distances and pretty much willing to turn the world around in the name of commitment - to provide for our families, while holding on to our ground to keep living up here. Throughout the conversation we had I couldn't help feel the commitment for providing not only workplaces up in the North but for actually getting work done right, in high quality and personal standards.


At this point everything was still fuzzy as to how the meetup would continue...
even fuzzier than the photo. But hey - we have some good food!


So what did we do anyway?
Apparently quite a lot. We had an agenda for 5-10 people but we ditched it in favor of a free conversation, aided by a whiteboard and a cellphone for youtube (this would probably not be possible with more than 3 people... looking at the bright side).

The first half of the conversation was mainly about work oppertunities. This is a major issue up north, and obviously one of the main motivators for the group - to create and discover new and better working and business oppertunities for northern practitioners. There have been many attemps to either bring talent and funding from the Tel Aviv area up north or to provide so-called-easy commuting means for northern folks to ocommute away. Most of these attempts have failed, and my personal feeling and belief is there are wonderful, skilled folks up here already. We are sure to find new ways of creating new venues for the local talent to prosper. Grooming this talent and connecting it to worplaces is one of the goals of the North Agile Galilee group.




The second half was actually crammed with agile topics - including:
  • Our board at the end of the meet
    Automated Testing - we learned from each other about new tooling including JSystem, Fitnesse and Selenium
  • How to get work DONE-DONE in a sprint?
  • Hardening Sprints - good or evil?
  • Scaling Scrum in a large organization
  • Throwing responsibility from Dev's to QA, and back.
  • Misconceptions about what is Agile? What constitutes a successful Agile adoption? (spoiler: it's *not* about taking a 1 day course and then throwing management out the window)
  • Misconceptions about what is a ScrumMaster? We watched Adam Weisbart's Shit Bad ScrumMasters Say in comparison to (sadly) real-life examples of what a scummaster is *not* supposd to to or be...
  • The role of Product Owner as opposed to the role of Product Manager
  • How do we handle Bugs in Scrum?
  • Kanban as a means of creating evolutionary change toward agility in an existing organizatin .



My own conclusions for next time:

  • Keep bringing good food.
  • Find a way to get meetup.com to support Rosh Pinna, or hold the meetup in a city the meetup.com supports. Either way - registration for next time will probably be a must. 
  • The next meetup is already aimed at the Carmiel/Misgav area. Even though I will be sad to get farther down north from the Northern Galilee Area, I'm looking forward to cooperating with some good folks in that area. North is North.
  • The misconceptions about what Agile is, what Scrum is and what is or is not possible are probably more common than I'd expected. So for the next meetup maybe it would be best to go back the basics - an introduction to Agile values - how it is about individuals and interactions, using working software as a means for tracking progress, creating collaboration with customers and responding to change.
All in all I am grateful for this experience and hopeful about creating a new and strong Northern Agile community.

** Huge thanks to MATI North Galilee for providing us with room and facilities, special thanks to Daphna who drove up especially on a Friday to make sure we have everything we need and to Ilana who helped us close up afterwards! **


Tuesday, April 23, 2013

How long will it take? Wrong question!

During a conversation with a client of mine we were reviewing an idea which would (hopefully) give hime a more cost-effective solution to a requirement he had than other alternatives.
He posed the follwing observation: "It still seems like it will take some time to complete, doesn't it?"

Now that observation struck me - it implicitly asks the question "How long will it take to complete?"

This question makes several assumptions:

  • There will be a certain point when the product will be "complete"
  • There will be a certain amount of time invested for reaching that point
  • The time invested will cost money, and therefore affect the ROI


Now looking at the assumptions from an Agile/Lean perspective, let's see how they can be looked at differently:

Assumption: There will be a certain point when the product will be "complete"

WRONG!

Agile mindset has come to relize that a product will *never* be complete.
In fact, we don't want it to be complete - why?
Because the business requirements and ecosystem are bound to change throughout the lifetime of the business.

We want to create a situation where the product can change accordingly, always changing to accomodate new requirements and new business opertunities.
A product which will be "completed" will stagnate and hold the business back in the long run instead of helping the business grow and evolve.

So we should replace this assumption with a question, or two questions in fact: 

  • What is the *minimal valueable next step* we can make in the evolution of the product to help it keep in sync with the *current* business requirements?
  • How can we make sure we can keep making such steps, such increments, in a sustainable pace in the future?


Assumption: There will be a certain amount of time invested for reaching that point

WRONG!

The point of completion is nonexistant, so there is no real meaning in asking how much time will be invested in getting there.

Instead, seeing as we want the product to keep changing and evolving, we should assume that each small increment will involve some time investment.

And what we shuld be asking is:

  • What is the least amount of time we can invest right now in making an increment which will bring us maximum value?

(we want to hold on to Paretto's law - finding the 20% of invested time which will produce an 80% increment in value)


Assumption: The time invested will cost money, and therefore affect the ROI

WRONG!

This assumption makes another assumption - that time invested would cost money and would not save us money.

Instead, consider the following:

  • Who is doing the work? if it's the customer himself, he is investing time but not paying anyone for it. So he is in fact saving money
  • What kind of work are we investing in? If we invest time in creating a bad solution, we might end up with a product that will cost us more in the long run (in terms of maintenance costs). If we invest our time in a "good" solution, it would mean a solution that reduces maintenance costs in the long run = saves us money.


So the question should be:

  • Can we invest the alloted time in teaching the customer how to do things himself instead of invesing in "hard labor manufacturing"? 
  • Can we invest the alloted time in solutions that will cost less in long term maintenance? (consider all costs involved in maintaining your product - including hsting costs, bugfixing, DBA work, website administration etc)


To Summarise:
Instead of asking "how long will it take"? consider time as having several dimentions:

  • Total (calendar) time - it is neverending and our product should keep evolving forever as long as the business keeps evolving
  • Invested time - Spread it. Instead of spending a big amount of time upfront, think of spending a little bit of time every now and then.
  • Cost - ask yourself how much that time costs you? How can you find ways to do more yourself (which will cost you nothing) and delegate "paid work" only for things you absolutely cannot do or for learnign how to do new things yourself
  • Savings - ask yourself can you invest  time in creating a solution that will reduce your long-term costs?


And remember - as Doctor Who puts it:
People assume that time is a strict progression of cause to effect, but *actually* from a non-linear, non-subjective viewpoint - it's more like a big ball of wibbly wobbly... time-y wimey... stuff. 

Enjoy your journey, enjoy your time :)