David Joyce's - A Journey to Systemic Improvement video link here
Mike Cohn - Synchronize Rather Than Overlap Sprints
It’s Not the Recession, You Just Suck
Moon Shots for Management Or Management 2.0 and its grand challenges Pdf link
How GANTT Charts could be built by using LEGO!
"You don't find customers for your products. You find products for your customers."
White Wizard @ Leavewizard.com | Continuous improvement catalyst | Agile, LeanStartUp, Kanban, SystemsThinking & Stewardship
Thursday, 24 December 2009
Tuesday, 22 December 2009
Agile links #2
Quickly after the first post here comes a second set of links:
Mentoring of candidates for CST many people have asked in the last year how to become a CST and here are the answers. Note that This is NOT an official set of requirements for CST application
Safecracking for the computer scientist Computers & security - by Matt Blaze
This is not like That Another (I am sure) brilliant post by Tobias Mayer which is in fact a repost of Lyssa Adkin's original post.
MANAGER 2.0: THE ROLE OF THE MANAGER IN SCRUM by Pete Deemer
Tester Types A humorous look at the different testing types according to Rob Lambert
Integration Management an interesting post on the PMI Agile Community of Practice Wiki which for some reason links one of my articles.
Mentoring of candidates for CST many people have asked in the last year how to become a CST and here are the answers. Note that This is NOT an official set of requirements for CST application
Safecracking for the computer scientist Computers & security - by Matt Blaze
This is not like That Another (I am sure) brilliant post by Tobias Mayer which is in fact a repost of Lyssa Adkin's original post.
MANAGER 2.0: THE ROLE OF THE MANAGER IN SCRUM by Pete Deemer
Tester Types A humorous look at the different testing types according to Rob Lambert
Integration Management an interesting post on the PMI Agile Community of Practice Wiki which for some reason links one of my articles.
Friday, 18 December 2009
Agile links #1
There is something about all the links to blog posts, articles, videos, etc. The information these sources have is usually very interesting. At the same time I find it more and more difficult to find enough spare time to read them all. I have tried emailing links to myself, tweeting to myself and many other tactics with mixed success but mainly no success ;). So Now I decided to stock them here on my blog so I have the links without growing my bookmarks to unmanageable level and still am able to access the links later when I find a few spare minutes. So here goes agile links #1:
People Polling @ tasty cupcakes
Systems Thinking: The Fifth Discipline of Learning Organizations By Marty Jacobs
Leadership and systems thinking.
Presentation Tip: How To Tell A Story
5 Secrets to the Hidden Job Market
Abolishing Performance Appraisals - a book I might buy
The Airplane Game - A pratical introduction to Agile/SCRUM
Notes on Starting an Agile User Group
100 Impediments A look at impediments a team may need to address.
That's all I have for now.. I hope this might be useful for someone else as well ;)
People Polling @ tasty cupcakes
Systems Thinking: The Fifth Discipline of Learning Organizations By Marty Jacobs
Leadership and systems thinking.
Presentation Tip: How To Tell A Story
5 Secrets to the Hidden Job Market
Abolishing Performance Appraisals - a book I might buy
The Airplane Game - A pratical introduction to Agile/SCRUM
Notes on Starting an Agile User Group
100 Impediments A look at impediments a team may need to address.
That's all I have for now.. I hope this might be useful for someone else as well ;)
Thursday, 19 November 2009
DEMING'S RED BEAD Experiment Replayed
I recently became aware of this experiment which Deming used to do in front of large audiences (e.g. 1200 people). Thanks to David and Benjamin the experiment comes to live again. It is worth watching at least the first 50 minutes and see for yourself this amazing story of processes, metrics, management, rewards and people.
http://skillsmatter.com/event/agile-scrum/demings-red-bead-experiment
http://skillsmatter.com/event/agile-scrum/demings-red-bead-experiment
Labels:
agile,
Deming,
Experiment,
Lean,
PDCA,
Skillsmatter
Friday, 6 November 2009
The Cool Wall Retrospective
Inspired by Mark Summer's post we decided to do a Cool Wall style joint team retrospective at the end of last sprint. These are scrum teams that work on the same project and often have cross team impediments or reasons to be proud.
It worked quite well, team said they liked it so we're doing it again. For more details on the technique check Mark's blog here
Labels:
agile,
Cool Wall,
Inspect and Adapt,
Retrospective,
scrum
Friday, 30 October 2009
CSM course in Bournemouth 23 & 24 November
Geoff Watts will be holding a CSM training course in Bournemouth on the 23/11/2009 and 24/11/2009. For full details see here
Tuesday, 13 October 2009
Scrum and Agile metrics follow up
While looking at metrics and what is appropriate I finally came across something that made sense to me and to the scrum masters in our department.
The information is from an article by Michael James which doesn't seem to be available any more unfortunately. The title of the article is An Agile ApproAch to “Metrics” and you may try to find it if you're more persistent than myself.
This article suggests to use a combination of 3 or 4 metrics. While I generally like the idea I am not sure all of them would work in our current environment. For example I would avoid using velocity in that sense although I would use it as a trend and not really related to the reports that Senior Management wants to do.
The two things that I reckon make sense are:
1. Delivered business value - i.e. every item has a business value and you count how much is being delivered
2. Running Tested Features which is something Ron Jeffries talks a lot about and we happen to do - e.g. a feature is RTF if it can be demoed from production build and passes automated tests (which should cover the acceptance criteria).
These two in combination make it difficult to game and also guarantee both business value and quality. While I am sure some people can still game them, I believe they represent a reasonable way to resolve the metrics problem.
The information is from an article by Michael James which doesn't seem to be available any more unfortunately. The title of the article is An Agile ApproAch to “Metrics” and you may try to find it if you're more persistent than myself.
This article suggests to use a combination of 3 or 4 metrics. While I generally like the idea I am not sure all of them would work in our current environment. For example I would avoid using velocity in that sense although I would use it as a trend and not really related to the reports that Senior Management wants to do.
The two things that I reckon make sense are:
1. Delivered business value - i.e. every item has a business value and you count how much is being delivered
2. Running Tested Features which is something Ron Jeffries talks a lot about and we happen to do - e.g. a feature is RTF if it can be demoed from production build and passes automated tests (which should cover the acceptance criteria).
These two in combination make it difficult to game and also guarantee both business value and quality. While I am sure some people can still game them, I believe they represent a reasonable way to resolve the metrics problem.
Tuesday, 11 August 2009
Agile metrics / Scrum Metrics
I very often hear about metrics in agile or what metrics shall we use in Scrum?
I recently came across Mary Poppendieck's suggestion about using the following "holistic measures":
1. Average Cycle Time – how long things take to go through the system.
for example - requirements from capture to acceptance and defects from
detection to correction.
2. The Business Case – Is the project still viable? If this isn't the case,
everything else is irrelevant.
3. Customer satisfaction – are your customers happy?
I wish I could try these one day.. instead my managers ask me to calculate the time spent on stories/projects and all types of coverage reports. Oh well.. ;)
I recently came across Mary Poppendieck's suggestion about using the following "holistic measures":
1. Average Cycle Time – how long things take to go through the system.
for example - requirements from capture to acceptance and defects from
detection to correction.
2. The Business Case – Is the project still viable? If this isn't the case,
everything else is irrelevant.
3. Customer satisfaction – are your customers happy?
I wish I could try these one day.. instead my managers ask me to calculate the time spent on stories/projects and all types of coverage reports. Oh well.. ;)
Monday, 10 August 2009
Twenty tips to write a good stored procedure (RB)
I came across a very useful list of tips for writing good Stored Procs by Arup Chakraborty here
I would say it can be combined with my set of best practices to include things like limiting the sets as early as possible.
Good read overall!
I would say it can be combined with my set of best practices to include things like limiting the sets as early as possible.
Good read overall!
Labels:
Performance,
SQL Server,
SQL Server Best Practices
Friday, 17 July 2009
The Wessex Scrum User Group
Our local Scrum User Group based in the South of UK has a new name - The Wessex Scrum User Group!
After months of exchanging emails with the Scrum Alliance, talking to the guys from the London Scrum User Group and discussing how to recruit more members we finally agreed on a name, the SA published our group profile here and we can also list all our events. We also have a new SA designed logo and some arrangements are in place to get experienced people (like CSTs) to visit us!
We have not yet created any website though and the only group place on the web is still the linked in group. Hopefully this will be the next thing on my list after the holiday season.
In the meantime looking forward to the next few meetings, especially the August one when we'll have a special guest - Geoff Watts! Also something to think about is the London Scrum Gathering in Feb 2010 which we may get involved in by contributing to the program and the organization.
Hope to get a good rest next week, as with Scrum Fest and Ken's visit last week it has been quite hectic.. not to mention the kick-off of the new project at work.
Labels:
Scrum Fest,
Scrum Gathering,
Scrum UK,
Wessex Scrum User Group
Wednesday, 10 June 2009
Effective coaching styles
Open space session notes from the Agile Coaches Gathering 2009 (Milton Keynes)
Key info:
- Facilitated by Xavier Quesada Allue
- Attendees that I remember: Rachel Davis, Manish Shah, Bob Marshal, David Draper, David Joyce, Manav Mehan (and many more + I hope all these guys really were there)
First we listed styles that we can think of including:
- Non directive style
- Leadership style
- Depending on what the person expects (adaptive)
- Trainer style
We recognized the fact that there are dimensions and styles. We looked at established coaching models like GROW (Goal, Reality, Options, Will), The Dreifuss model, The solution focus model based on getting the goals out of the coachee.
Then we talked about capability coaching and the thoughts I listed on this were various approaches and questions to ask like:
- Interesting! Tell me more? (instead of reacting negatively and directing)
- Why? – Perhaps replace with “what would that give you?” or “what would that result in?”
- What value does that give us? Is that what we want?
- Get going (not sure about this one, perhaps related to do and then inspect.)
- Look at all the issues (e.g. impediments, problems) and prioritize – perhaps phrase this as question
Somebody asked the question – Do you have to have all the styles? And the answer came that you certainly need a set of styles. How do you find out how effective your style is? Watch other people coach in action (Shadowing; Pair-coaching).
You need to ask yourself the questions – Who you are being and what you’re doing. You can have the same or different model and perhaps slightly different style.
You may want to think about 3 adjectives that you would use to describe this person like best at? Or worst at?
How to find out if you’re effective? Can remote coaching be effective? You rely on hearing only and lose the body language. Near coach/far coach model.
Coaches should not be part of the system – if you are then you’re missing coaching opportunities. Your goal as a coach should be the improvement of the team.
The team must respect you. You have to be visibly doing stuff. If you quickly show/add a bit of value then you get respect. You also need to show respect. Consider if the team has actually asked for a coach?
[An interesting related book is “The speed of trust”]
There are 3 factors:
- Character
- Competence (It has been noted that it is easier to coach if you’re less competent as you do not direct)
- Consistency (develops over time and sets predictable behaviour)
For example coaching a tester can be effective even though you don’t know anything about testing.
You perhaps need some basics – e.g. TDD, principles, knowing concepts and tools.
Coaching is to help someone move forward.
[A good book to check is Quiet Leadership.]
Key info:
- Facilitated by Xavier Quesada Allue
- Attendees that I remember: Rachel Davis, Manish Shah, Bob Marshal, David Draper, David Joyce, Manav Mehan (and many more + I hope all these guys really were there)
First we listed styles that we can think of including:
- Non directive style
- Leadership style
- Depending on what the person expects (adaptive)
- Trainer style
We recognized the fact that there are dimensions and styles. We looked at established coaching models like GROW (Goal, Reality, Options, Will), The Dreifuss model, The solution focus model based on getting the goals out of the coachee.
Then we talked about capability coaching and the thoughts I listed on this were various approaches and questions to ask like:
- Interesting! Tell me more? (instead of reacting negatively and directing)
- Why? – Perhaps replace with “what would that give you?” or “what would that result in?”
- What value does that give us? Is that what we want?
- Get going (not sure about this one, perhaps related to do and then inspect.)
- Look at all the issues (e.g. impediments, problems) and prioritize – perhaps phrase this as question
Somebody asked the question – Do you have to have all the styles? And the answer came that you certainly need a set of styles. How do you find out how effective your style is? Watch other people coach in action (Shadowing; Pair-coaching).
You need to ask yourself the questions – Who you are being and what you’re doing. You can have the same or different model and perhaps slightly different style.
You may want to think about 3 adjectives that you would use to describe this person like best at? Or worst at?
How to find out if you’re effective? Can remote coaching be effective? You rely on hearing only and lose the body language. Near coach/far coach model.
Coaches should not be part of the system – if you are then you’re missing coaching opportunities. Your goal as a coach should be the improvement of the team.
The team must respect you. You have to be visibly doing stuff. If you quickly show/add a bit of value then you get respect. You also need to show respect. Consider if the team has actually asked for a coach?
[An interesting related book is “The speed of trust”]
There are 3 factors:
- Character
- Competence (It has been noted that it is easier to coach if you’re less competent as you do not direct)
- Consistency (develops over time and sets predictable behaviour)
For example coaching a tester can be effective even though you don’t know anything about testing.
You perhaps need some basics – e.g. TDD, principles, knowing concepts and tools.
Coaching is to help someone move forward.
[A good book to check is Quiet Leadership.]
Thursday, 4 June 2009
Value, Flow, Waste
I heard somebody talking about these three in the same sentence a couple of weeks ago and accidentally (or perhaps now) used them in a presentation draft while trying to explain what in Scrum we'd separate as functional/non-functional.. and waste although it doesn't seem to come up that often as the other two.
Anyway so I had to explain what it is as the word Value seem to be causing hiccups with some of our managers and the shorter explanation I could think of was that value is what we get money for, flow is what makes possible the production of value and waste is all that doesn't add to any of the other two so we throw it away.
I then ended up searching for more info and discovered 5 principles of lean (as opposed to the more famous 7). Here they are:
1. Specify value
2. Identify the value stream
3. Make value flow
4. Let customers pull
5. Pursue perfection (e.g. identify waste and eliminate continuously)
Ok, so the connection is that these 5 principles well explain the title as well and I am going to use them when I talk about it in about 10 days time. I may even post something about the event as it is my first ever agile project initiation boot camp.
Anyway so I had to explain what it is as the word Value seem to be causing hiccups with some of our managers and the shorter explanation I could think of was that value is what we get money for, flow is what makes possible the production of value and waste is all that doesn't add to any of the other two so we throw it away.
I then ended up searching for more info and discovered 5 principles of lean (as opposed to the more famous 7). Here they are:
1. Specify value
2. Identify the value stream
3. Make value flow
4. Let customers pull
5. Pursue perfection (e.g. identify waste and eliminate continuously)
Ok, so the connection is that these 5 principles well explain the title as well and I am going to use them when I talk about it in about 10 days time. I may even post something about the event as it is my first ever agile project initiation boot camp.
Thursday, 21 May 2009
Unit Testing ASP.NET? ASP.NET unit testing
Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.
Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.
Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.
Wednesday, 29 April 2009
South UK Scrum User Group, 27th April 2009
Getting an acceptable definition of done
[Notes from 27th April 2009, South UK Scrum User Group]
The level of granularity is important, which is why we define the definition of done at four levels: release, sprint, story and task.
At the task level we look at the following:
- Developer says it is done
- Unit test exists and passes
- The code is in the trunk
- Code coverage is above the target (e.g. 90%)
- More criteria can be used as function points, analysis coverage, cop type coverage
- Tracking system is updated
- Check-in is reviewed
- The work is reviewed
At the sprint level we define the following:
- All agreed stories are done
- Held a retrospective which is documented
- Show and tell demo
At the Release level the criteria are:
- All sprints are done
- Media is produced (e.g. CDs, marketing materials)
- User documentation has been reviewed (e.g. by the user community)
- Install and release notes are ready
- External testing or audits are performed (e.g. security audits)
- PO signs it off
The definition of done for Story include:
- All tasks associated with the story are done
- The story is integrated and tested
- Acceptance criteria is met
- Installation works
- Documentation is done
- Product owner accepts the story
[Notes from 27th April 2009, South UK Scrum User Group]
The level of granularity is important, which is why we define the definition of done at four levels: release, sprint, story and task.
At the task level we look at the following:
- Developer says it is done
- Unit test exists and passes
- The code is in the trunk
- Code coverage is above the target (e.g. 90%)
- More criteria can be used as function points, analysis coverage, cop type coverage
- Tracking system is updated
- Check-in is reviewed
- The work is reviewed
At the sprint level we define the following:
- All agreed stories are done
- Held a retrospective which is documented
- Show and tell demo
At the Release level the criteria are:
- All sprints are done
- Media is produced (e.g. CDs, marketing materials)
- User documentation has been reviewed (e.g. by the user community)
- Install and release notes are ready
- External testing or audits are performed (e.g. security audits)
- PO signs it off
The definition of done for Story include:
- All tasks associated with the story are done
- The story is integrated and tested
- Acceptance criteria is met
- Installation works
- Documentation is done
- Product owner accepts the story
Labels:
Definition of Done,
scrum,
UK South Scrum User Group
Friday, 20 March 2009
First UK South Scrum User Group Notes
On 18th this months in a nice pub in Ringwood we had the first ever UK South Scrum User group meeting.
I tried to take as many notes as possible for the benefit of the group members and hopefully the entire Scrum community.
Here's what I managed to write down:
What do we want to achieve with this group?
- Get people to come along and chat (about Scrum and Agile)
- Meet once a month every 3rd Tuesday (this has not changed to last Monday of the month)
- Talk about common issues and ways to resolve them
How do we do it?
We will experiment and pick one of the following or perhaps something else if these are not suitable:
- Open space discussions
- Goldfish bowl
- World cafe
How do we make people aware about this group?
- Ask people who do training for contacts
- Blog about it
- Announce it to NextGen members
- Make it regular – regular day and location
How big do we want it to be? The bigger it is the more structured it has to be.
- Could have perhaps a “learn about Scrum” session
- Talk to big Scrum/Agile consultancies like Conchango/EMC or RallyDev about sending speakers.
- Clive and Plamen to talk with Roman on 8th April (London Scrum User Group) about getting the group listed on the Scrum Alliance website.
We then talked about the biggest challenges that each of us recognises. I have recorded hopefully most of these:
- Getting acceptable definition of done – everyone to sign up for it [This has also become the topic of our next meeting on 27th April)
- Guiding/Coaching ScrumMasters that are new to Scrum and making them become Scrum advocates
- Getting full Senior Management support in a big organisation
- Change process as a whole and trying to implement it into large organisations
- Requirements – getting the definition of them, making them agile requirements.
- Technical gold plating – when to do just enough architecture, design ,etc.
We then went on to talk about positive experiences and again I hope I recorded most of them:
- Team refused to estimate as no answers were given to important requirements questions
- Team no longer delivers the wrong solution
- Team response to HR attempt to impose individual performance reviews.
- Team managed to isolate maintenance to overcome problems with delivering
- The “War room” and winning it from the business just for Scrum use by the teams
- Throwing away the concept of in-sprint defects and no longer wasting time to log them into some system. Get the testers talking rather than typing.
Other thoughts or discussions were around:
- Getting people to understand what is realistically done and optimistically done
- Tech authors could be key as while wanting to know more they lead the information sharing and steer teams towards delivering the user stories
- Important thing is to have the right ratio QA/Developers
- Tools in use include: Rally, TFS, Version One, Target Process (also has helpdesk) and xProcess.
Overall a very good evening and lots of ideas have been discussed. We also managed to set up date for the next meeting, agree on actions about making people aware about the group and identified the main topic for next time.
I hope to see you all there and hopefully a few more people will turn up as well!
I tried to take as many notes as possible for the benefit of the group members and hopefully the entire Scrum community.
Here's what I managed to write down:
What do we want to achieve with this group?
- Get people to come along and chat (about Scrum and Agile)
- Meet once a month every 3rd Tuesday (this has not changed to last Monday of the month)
- Talk about common issues and ways to resolve them
How do we do it?
We will experiment and pick one of the following or perhaps something else if these are not suitable:
- Open space discussions
- Goldfish bowl
- World cafe
How do we make people aware about this group?
- Ask people who do training for contacts
- Blog about it
- Announce it to NextGen members
- Make it regular – regular day and location
How big do we want it to be? The bigger it is the more structured it has to be.
- Could have perhaps a “learn about Scrum” session
- Talk to big Scrum/Agile consultancies like Conchango/EMC or RallyDev about sending speakers.
- Clive and Plamen to talk with Roman on 8th April (London Scrum User Group) about getting the group listed on the Scrum Alliance website.
We then talked about the biggest challenges that each of us recognises. I have recorded hopefully most of these:
- Getting acceptable definition of done – everyone to sign up for it [This has also become the topic of our next meeting on 27th April)
- Guiding/Coaching ScrumMasters that are new to Scrum and making them become Scrum advocates
- Getting full Senior Management support in a big organisation
- Change process as a whole and trying to implement it into large organisations
- Requirements – getting the definition of them, making them agile requirements.
- Technical gold plating – when to do just enough architecture, design ,etc.
We then went on to talk about positive experiences and again I hope I recorded most of them:
- Team refused to estimate as no answers were given to important requirements questions
- Team no longer delivers the wrong solution
- Team response to HR attempt to impose individual performance reviews.
- Team managed to isolate maintenance to overcome problems with delivering
- The “War room” and winning it from the business just for Scrum use by the teams
- Throwing away the concept of in-sprint defects and no longer wasting time to log them into some system. Get the testers talking rather than typing.
Other thoughts or discussions were around:
- Getting people to understand what is realistically done and optimistically done
- Tech authors could be key as while wanting to know more they lead the information sharing and steer teams towards delivering the user stories
- Important thing is to have the right ratio QA/Developers
- Tools in use include: Rally, TFS, Version One, Target Process (also has helpdesk) and xProcess.
Overall a very good evening and lots of ideas have been discussed. We also managed to set up date for the next meeting, agree on actions about making people aware about the group and identified the main topic for next time.
I hope to see you all there and hopefully a few more people will turn up as well!
Labels:
scrum,
ScrumAlliance,
UK South Scrum User Group
Thursday, 12 February 2009
Scrum User Group in the South (outside London)
A fellow scrummer based in dorset has posted this yesterday and emailed the scrum development yahoo group with an idea to organise Scrum UG in close proximity to BH, SO, PO. I then decided to join him in an attempt to gather enough people and created this linked in group. If you happen to somehow find this post and live in the area and are interested in participating in a Scrum UG please join the linked in group.
Tuesday, 27 January 2009
Ron Jeffries answering 5 Scrum questions
I always enjoy reading Ron Jeffries' posts and they are one of the reasons for me to subscribe to as many agile yahoo mail groups as my mailbox is comfortable with.
So when I found, this short interview I thought it is brilliant, just like reading about 10 posts at once which usually means lots to learn from a great agilist in just a few minutes of reading.
So when I found, this short interview I thought it is brilliant, just like reading about 10 posts at once which usually means lots to learn from a great agilist in just a few minutes of reading.
Wednesday, 21 January 2009
Въведение в Скръм (IntroToScrum) на Български е публикувана!
След много дълго продължил превод и доста по-бързо направени ревюта от:
проф. Аврам Ескенази
и
Георги Стойчев
успях да направя корекциите и изпратих първия вариант на презентацията която Майк публикува вчера на този адрес.
Междувременно се оказа че има още желаещи да помогнат с подобряването на превода така че скоро ще има обновена версия.
Много се надявам това да се окаже полезно и да допренесе за популяризиарнето на гъвкавите методи и в частност Скръм в България.
П.С. Това ми е и първият постинг на Български ;)
проф. Аврам Ескенази
и
Георги Стойчев
успях да направя корекциите и изпратих първия вариант на презентацията която Майк публикува вчера на този адрес.
Междувременно се оказа че има още желаещи да помогнат с подобряването на превода така че скоро ще има обновена версия.
Много се надявам това да се окаже полезно и да допренесе за популяризиарнето на гъвкавите методи и в частност Скръм в България.
П.С. Това ми е и първият постинг на Български ;)
Monday, 12 January 2009
Scrum Gathering Stockholm 2008: Day 1, More afternoon sessions
(I am) terribly late again... but I am sure I still have a chance to finish publishing before the next gathering takes place (hopefully).
I chose to attend a session about the Scrum Implementation at Man Investments. First thing to notice was a guy that looked very familiar to me... so familiar that I later on went to speak to him but it turned out he just reminds me of someone but he is not that guy.. Anyway the presentation was great, mainly because it was by a UK based companies so they seemed to be facing pretty much the same cultural issues as we do. They seemed to have obtained better support on director’s level and also have spent extensively on Scrum training. Unfortunately the last is not something I can hope for.
I thought it is worth noting that they managed to get an actually business analyst to be the product owner of one of their teams and even better the guy was there and spoke a little about his experience. Apart from being a typical *business* type (e.g. would try to sell you anything) he left me with the impression that he actually “got it”. And he also hit me with another sad reality thing – they did Scrum training for the business side... something that in our company would be a huge struggle to do... I guess again it is down to the level of support from the C*Os.
Something we now beat them at was the integration; they stated they integrate every sprint while in fact we strive to integrate every day or 2 days max. And for the first time I’ve heard about real experience in a joint planning session where you have more than one teams working on the same backlog. I would imagine that is a bit difficult to manage but for the time being we don’t need to do that.
And they carried on presenting more and more useful tips like the code coverage metric which we are now trying to introduce, user stories workshop with the business involved - not that we don’t know about it but again how much support is needed to get that done?! Good suggestion was the fact that they allow about 10 points for technical debt when trying to improve existing legacy code. This alerted us to something but we try to estimate the non functional work and add it to the backlog – we came to conclusion that this makes more sense.
On the last session for the day the speaker actually didn’t turn up so we had a discussion where Robyn Dymond initiated the format of having a 3-4 chair panel in front (as if they are the speakers) with the simple rules that only when all chairs are filled with people and only people sitting in front can speak. It was a valuable experience and I wish to try this format soon. We discussed many issues including how to ensure team does not become stale, how to sustain improvement and others.
Overall it was a great first day that ended with a rather weird sponsor cocktail but if we were to ignore all the talking the free beer and decent food were good enough reason to spend some more time in the conference building.
I chose to attend a session about the Scrum Implementation at Man Investments. First thing to notice was a guy that looked very familiar to me... so familiar that I later on went to speak to him but it turned out he just reminds me of someone but he is not that guy.. Anyway the presentation was great, mainly because it was by a UK based companies so they seemed to be facing pretty much the same cultural issues as we do. They seemed to have obtained better support on director’s level and also have spent extensively on Scrum training. Unfortunately the last is not something I can hope for.
I thought it is worth noting that they managed to get an actually business analyst to be the product owner of one of their teams and even better the guy was there and spoke a little about his experience. Apart from being a typical *business* type (e.g. would try to sell you anything) he left me with the impression that he actually “got it”. And he also hit me with another sad reality thing – they did Scrum training for the business side... something that in our company would be a huge struggle to do... I guess again it is down to the level of support from the C*Os.
Something we now beat them at was the integration; they stated they integrate every sprint while in fact we strive to integrate every day or 2 days max. And for the first time I’ve heard about real experience in a joint planning session where you have more than one teams working on the same backlog. I would imagine that is a bit difficult to manage but for the time being we don’t need to do that.
And they carried on presenting more and more useful tips like the code coverage metric which we are now trying to introduce, user stories workshop with the business involved - not that we don’t know about it but again how much support is needed to get that done?! Good suggestion was the fact that they allow about 10 points for technical debt when trying to improve existing legacy code. This alerted us to something but we try to estimate the non functional work and add it to the backlog – we came to conclusion that this makes more sense.
On the last session for the day the speaker actually didn’t turn up so we had a discussion where Robyn Dymond initiated the format of having a 3-4 chair panel in front (as if they are the speakers) with the simple rules that only when all chairs are filled with people and only people sitting in front can speak. It was a valuable experience and I wish to try this format soon. We discussed many issues including how to ensure team does not become stale, how to sustain improvement and others.
Overall it was a great first day that ended with a rather weird sponsor cocktail but if we were to ignore all the talking the free beer and decent food were good enough reason to spend some more time in the conference building.
Labels:
agile,
scrum,
Scrum Gathering,
ScrumAlliance,
Stockholm
Subscribe to:
Posts (Atom)