23 January 2013 Meeting

This was our welcome to 2013 meeting. Apologies for the lack of blog posts lately. Our meetings have been going on strong but I need to streamline the blogging process.

Uploading photos of notes is great in concept but I have struck quite a few technical headaches I won’t bore you with, so here are the notes:

 

What Are 20 Questions I Can Ask to See if Someone is a Scrum Expert

  1. Describe scrum roles
  2. Describe an iteration – what happens, what ceremonies when
  3. Where is Scrum defined? (Do they know about the Scrum Guide?)
  4. In scrum who is responsible for (be careful of text book answers here, roles here need to be carefully constructed)
    1. Database design
    2. Architecture
  5. Who prioritises the work?
  6. When do you do retrospectives?
  7. What real world modifications to scrum have you used?
  8. What definitions of done have you used?
  9. What is the best day of the week to start the sprint?
  10. How do you handle refactoring?
  11. How do you handle design and architecture in scrum?
  12. How do you handle risk in scrum? (Interesting area – my Scrum Trainer proclaimed he had ‘never done risk management in his life’, I have the deepest respect for him so my interpretation of that is that he did do it, he just didn’t call it that and didn’t use any traditional approaches to manage it)

We went off then into an interesting discussion on S.O.D or “Sign Posts of Danger”. One attendee has  a long list of project danger signposts and shares these with the team at kick offs. They then add to it and all agree that it is everyone’s responsibility to highlight when you see any of these.

How to Combine Lean Startup with Scrum

  • be careful of expectations – the outcome of 1 sprint won’t be a ‘finished product’
  • need to balance generating a backlog / estimate with focusing early sprints on learning and delivering basic way to solve the problem

 

Creating a Culture that Embraces Failure

  • Every project should have a business case and a business owner that signs up and will be accountable for that – “agile or not”
  • ie failure to do this is not a failure that should be tolerated easily

And in relation to combining Scrum and lean startup and failure:

  • at the end of each sprint – ask can the business owner sign up to benefits and can the dev team sign up to estimate and do we know what the next MVP is

We had lots more discussion on failure, but I didn’t keep too many notes. Some key ideas:

  • this culture must be supported from the top of the organisation
  • it’s ok to fail just do it early and ensure everyone has the same picture of why it failed and what you plan to do to stop that happening next time – value the learning

 

Posted in Uncategorized | Tagged , , , | Comments Off on 23 January 2013 Meeting

14 November, 2012

Topic #1: The practicalities of defining a software MVP

Using MOSCOW: List the extra customer demands’ and do a minimal research to verify if the demands realistic.

  • Mockup:
  1.  Create a basic UI to make it simple& easy to understand what the features should cover.
  2. Keep a log of customers’ wish list and rank the most desired features. Then decide if to add it to your core product or as add-ons.
  • Build external services to the software
  • Design / Build a core functionality / product with an option to add extra services / add-ons. Enable creation of selling packages to answer the demand of different customer segments in the market.
  • Try to propose workarounds to customers’ process within the system to make it cheaper and quicker.

Topic #2: Lean teams: To what extent the team should be take decisions about the product?

  • 2 team should exist:
  1. A business team: Leaders that have the responsibility to speak with the customer and to represent the company on business aspects.  they will  choose the business / tech people to represent the solution to the customer.
  2. The technical team
  • The goals should be clear to all.
  • The team should be empowered to make decisions
  • Escalation criteria should be set, to address problems
  • The suggested process:
    1. When customer requirements are collected; only the business people should be involved. If technical gaps are found then the tech guy enters the picture.
    2. Sing post of danger: The team should react when risk is exposed:
    3. The team should  stop
    4. Define the risk and alternatives to what they should do / escalation.
    5. Risks are taken in consideration when the backlog / requirement are prioritized.

 

 

 

 

 

 

Posted in Uncategorized | Leave a comment

17 October, 2012

Topics today: “What do Business Analysts add to Lean Projects” and some general chat about career backgrounds.

Continue reading

Posted in Uncategorized | Tagged , , | Leave a comment

Meeting 3 Oct 12

Topics 3 Oct 12

 

 

See what we discussed…

Continue reading

Posted in Uncategorized | Tagged , , | Leave a comment