Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
I am introducing agile to a large, Fortune 500 company that still uses COBOL. People seem willing and excited but it's very new. Does anyone have good recommendations to introduce agile?
5) We're going to use XPlanner to give people more visibility into the process.
I'm also debating doing the XP Game Description. Has anyone tried it?
- Any other reading materials (not books, but something lighter that people will definately read, not just browse through)?
- Any other suggestions for how to get people up to speed?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
The James Shore article was a good recommendation. I've read Kerth, but this is a great framework for an itration retrospective.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Mark Herschberg:
The James Shore article was a good recommendation. I've read Kerth, but this is a great framework for an itration retrospective.
--Mark
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mark Herschberg:
I've used Xplanner before and deador not, I found it valuable.
Still, I want to give the team whatever it prefers.
Cards:
+ can touch them
+ easy to move around
+ visible to team on the wall
+ visible to others walking into the room
- no metrics
XPlanner:
+ easier to organize (we're expecting 500+ stories)
+ visible to anyone in the company
+ good metrics with graphical representations
- not as easy to see big picture
- not as tangible
Then we could consider hybrid models, such a cards + excel (for metrics), or XPlanner + current iteration cards (for the wall).
Any thoughts? What else have I missed?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
- Any other suggestions for how to get people up to speed?
M Easter
Software Composer - http://codetojoy.blogspot.com
Originally posted by Mark Herschberg:
As a side note, what story size have you found works well? I've seen anything from a few days to a few weeks in methodology descriptions. I prefer a few days as the upper limit, but we may have to go slightly larger for some particular stories given that we're still defining the business.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Mark Herschberg:
We used XPlanner 0.7b2. What were the technical issues you found?
How many stories did you have? We had I think somewhere between 100-150 and about 30 of them went into a 1 month sprint.
As a side note, what story size have you found works well? I've seen anything from a few days to a few weeks in methodology descriptions. I prefer a few days as the upper limit, but we may have to go slightly larger for some particular stories given that we're still defining the business.
The metrics with XPlanner seemed sufficent to me, but this was over a year ago, so maybe I'm forgetting something we wanted that it didn't have. What did you want that it didn't provide?
Of course, following the standard practice of reviews, if we don't like how we're doing it, we can switch later.
Does a webcam provide enough resolution that people can see it?
As for using cards and XPlanner, I agree 110% that it's a risk/problem duplicating work. That said, this is what the team thinks is most efficent.
(one of the big concerns of team members, rightly or wrongly, is that physical cards can accidentally fall off the wall and get lost)
On that note, have you used color coding schemes, and if so what works well?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
One other question (I'll respond to your other comments tonight), on previous projects I've used "developer stories." That is the business owners never think about things like logging, but the developers, knowing that they'll need it, and not having it fit into any other stories, create what I've called "developer stories." These are stories they think should be a part of it. They don't add "direct" business value but do provide issues like stability and reliability to the system. It still gets to be prioritized by the business owners (although usually the developers get a little more influence in terms of pushing for these stories). How else do companies handle things like this?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Mark Herschberg:
By "defining the business" I mean on most of your project you knew how the business worked, you mght be replacing a legacy system, or automating a process, or implementing a new process smeone dreamed up. Right now we're at the stage of, to use eBay as an anaology, "let's create an online auction house." Which leads to questions like "how do we make money?" "how do people register?" "what are the legal implications?" "how is money transfered?" "how is responsibile if something goes wrong?" We don't have those questions answered, since the business is onl a few weeks old. We're working through them.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Lasse Koskela:
Another term for this kind of items I've heard used a lot is "technical stories". You might want to try expressing such stories in a way that brings out the benefit to the business. For example, if you now have the following story...
Implement a uniform logging solution
...then that story could be expressed in a more business-friendly style as, for example...
Implement a uniform logging solution so that the mean time to fix a defect is reduced
That already makes the "indirect" business benefit explicit. You might even try to experiment with quantifying the improvement, if applicable.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
If I understood correctly, you said that this might lead to bigger stories that you can't break down further?
I'm wondering why that would be the case. And I actually wonder how you could implement a story that you can't possibly break down further.
Originally posted by Ilja Preuss:
When I'm working on a story where I think logging is necessary, I'll just implement it as part of the story. It's a technical decision, just like the decision to write a test, to refactor, or to use a for loop. I don't need to ask the customer to do that - if I subscribe to the idea that logging is part of developing a system effectively, it's just part of my professional behaviour.
When I implement logging in the second story, professional behaviour just asks me to not duplicate code. That will naturally lead me to a "uniform logging mechanism", as part of my normal work. No need to ask for permission to do that.
Assuming that we already have a working system where I think the logging is insufficient, I still don't need an explicit story. It's just part of my professional behavior that fixing a bug also includes reducing the likelihood of the same or a similar bug being introduced again, and when the bug was hard to fix because of missing information, making it easier to get that information in the future. So introducing logging - if it's the right solution - will just be a natural part of fixing a bug.
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
Certainly by the time they are in a sprint, we'll need to have them well defined and withing our 3 day limit, but while on the backlog they may stay in larger chunks.
I'm still dubious on this, but I think it gets back to our debate a few years back where I think one of the wekeaness of agile is sometimes you don't see the forrest for the trees (and I'm skeptical of walking skeletons and the spike method).
BTW, what other mailing lists/forums do you recommend for questions like these?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Michael Finney - "Always Striving To Serve You Better Every Day"
http://www.smilingsoftwaresolutions.com/
Originally posted by Mark Herschberg:
For example, right now the CIO wants a set of milestone dates so that if we miss any of the dates, they can appear as alerts on her dashboard.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Don't get me started about those stupid light bulbs. |