Pain Points and GAPS in our SDLC Process
Greg
-ASP.NET 3.5 SaaS Web Application; 2 years in Production
-3rd Party/Vendor offshore development team
-5 developers, 1 QA, 1 Engineer/Project Manager on that offshore team;
this team is not employed by us
Physical Environments:
Production, Staging and QA.
The developers do their development locally, their work gets promoted
to our QA environment where their QA person tests. Bugs get fixed, re-
tested and then they do a promotion to Staging where we do our User
Acceptance Testing. From there a promotion is done to Production once
we give the green light in Staging.
Internally I manage all Software Development and Integration Projects
(we are currently integrating with 2 Saas products and have plans for
more).
We are trying to be Agile with our SDLC but like businesses we are
given deadlines by the business folks.
We do a good job gathering and documenting requirements, but like most
shops scope creep is also an issue. We do a pretty good job managing
it but again if business says it has to change, it changes.
For our current release we did 4 Sprints. A sprint is 3 weeks of
development by the developers. Every week a QA build is done for the
QA person to start testing locally. The 4th week of the Sprint is for
fixing bugs found in QA. This week is also when the QA person promotes
a build to our QA environment where QA testing continues with the
addition of regression testing.
For the Agile/Scrum Masters out there, where are our Gaps? The first
big one I see is we are driven by dates. I have little control over
that. So, do we throw Agile out the door? The business folks are good
at recognizing in order to get new stuff in, stuff has to come out, so
Agile "works" for us in that sense; though we are still driven by
dates.
The offshore team is a challenge for us too; especially since they are
not our employees. How do other folks use Agile when the development
and QA folks are not your employees AND are offshore?
How to document requirements has always been a challenge for me with
Agile. We do not use cards, never been able to sell it. We start with
a master/full list of requirements, meet with business to prioritize
them and then figure out how much we can get into a Sprint. This
"feels" Agile but I am not convinced it really is.
Once a requirement is documented and prioritized and then there is a
change to the requirement is a challenge for us to. We keep everything
in SharePoint, so we have Versions. Traceability is a problem though.
When was the change made? Why? Who drove the change? Who approves the
change? How do folks manage this in an Agile environment?
Another challenge we have is our software vendor uses their system for
project and bug tracking, we use WORD, Excel, VISIO, etc and then
SharePoint for file management. We use their system too (we upload our
documents to their "tickets" and add Comments to their tickets as
needed), but we always have 2 systems of record and we always wonder
if they are in synch. The only way to know is to keep doing audits;
which takes time. We do not want to use their system 100% as they may
not always be around (they go out of business, we go with another
vendor, we bring development in-house, etc).
With Agile, release early and release often makes sense. Are we
following this by doing 4 weeks Sprints, where at the end of the 4
weeks the goal is to promote a build to Staging for us to do our UAT?
Then, when we finish UAT should it go to production? Or, like it does
now, should we wait for everything to be completed (all 4 sprints in
this case)? Our plan for Staging was for UAT and then a place for
internal users to test and see the new features before they go to
production.
Should we even be trying to be Agile if business and dates will always
drive a release schedule?
We are wrapping up a big Release (4 4 week Sprints). We want to make
changes now for the next big release.
Thanks for any input/feedback.
mheusser
>little control over that.
>
up of the classic definition of Scrum in "Righteous Problems, Wicked
Solutions."
I have had some success with saying something like this:
"Ok, we know we need it on January 15th. That's okay. We also know
the scope with change between iterations -- That's okay too. What I
can promise is that the things at the top of the list -- the ones you
say need to be done, that stay at the top of the list -- those things
will be done and delivered on January 15th.
We can deal with changing requirements, that just means that what we
plan to deliver will change over time. Since we know it will change,
I can't tell you what we plan to deliver -- we don't even know what we
want at this point, right?"
----> If, on the other hand, you are saying the business wants to make
up an infinite list of features, add to it as it sees fit, and insist
that everything on the list be delivered on January 15th, well,
politely, /*NO*/ that is not something that all businesses do, nor is
it something other disciplines just "have" to "put up with" as "part
of doing business." (I'm not quoting you, those are just terms I have
heard in the past to justify the "horn of plenty" approach to IT.)
The thing about the horn of plenty is that it is a /mythical/
device. /Myth/.
Does that help?
--heusser
Greg
Our stakeholders are good at understanding in order to get something
new in, something existing has to come out.
Ron Jeffries
Overall, it does not sound to me as if you are doing anything very
much like good Scrum or Agile. I'm wondering if you think you are,
or if you're just looking for ideas to move in that direction.
I'll comment a bit ...
On Friday, November 26, 2010, at 9:11:26 AM, you wrote:
> We are trying to be Agile with our SDLC but like businesses we are
> given deadlines by the business folks.
That is fine. The essence of Agile, in my opinion, is managing scope
to hit any desired date. (One part of that is that the team has the
software /always/ ready to deploy. Sounds like you're not doing
that.
> We do a good job gathering and documenting requirements, but like most
> shops scope creep is also an issue. We do a pretty good job managing
> it but again if business says it has to change, it changes.
In "good Agile", the business controls what is done, while the team
controls how much is done. If the business wants to add something,
that's fine. They are implicitly giving something up, and if they
are wise, they will choose carefully what that is.
> For our current release we did 4 Sprints. A sprint is 3 weeks of
> development by the developers. Every week a QA build is done for the
> QA person to start testing locally. The 4th week of the Sprint is for
> fixing bugs found in QA. This week is also when the QA person promotes
> a build to our QA environment where QA testing continues with the
> addition of regression testing.
Almost every Agile team these days is operating in two week Sprints.
At the end of two weeks, all the stories are done, complete, ready
to ship. (This doesn't happen at the beginning. It had better happen
early on, or they won't be ready to ship when they need to.)
Using separate QA does not work well, as it means a strange shift in
workload over the course of the Sprint. Creating acceptance tests
FIRST rather than last makes things go much better, as the
programmers continue to work until the tests run. This reduces
rework and task switching.
> For the Agile/Scrum Masters out there, where are our Gaps? The first
> big one I see is we are driven by dates. I have little control over
> that. So, do we throw Agile out the door? The business folks are good
> at recognizing in order to get new stuff in, stuff has to come out, so
> Agile "works" for us in that sense; though we are still driven by
> dates.
Agile is fine with dates. Your process does not seem to me to be
very Agile, as I mentioned. Perhaps you could tell us a bit about
the training and coaching your team has had.
> The offshore team is a challenge for us too; especially since they are
> not our employees. How do other folks use Agile when the development
> and QA folks are not your employees AND are offshore?
I'm not clear here, I find. Is /all/ the development being done
offshore, or just some of it? If all, in what way do you think your
current scheme is Agile?
Actually, now that I think of it, please describe in any case how
your approach seems to you to match with Agile. That would be
helpful, I'm sure.
Offshoring is very difficult. Fundamentally it is just a cheaper way
to fail for most people. It is possible to do it successfully, I'm
told. I've never seen it. Basically you'll need to coordinate them
as you would have otherwise, in the best way you know how. Agile per
se offers no particularly thrilling advice on this. My own advice is
"Have you noticed how badly this works? What does that suggest to
you?" :)
> How to document requirements has always been a challenge for me with
> Agile. We do not use cards, never been able to sell it. We start with
> a master/full list of requirements, meet with business to prioritize
> them and then figure out how much we can get into a Sprint. This
> "feels" Agile but I am not convinced it really is.
It's OK. Note that a full list of requirements is wasteful to the
extent that many of them are not going to be done. On the other
hand, it may not take long to create or maintain so it may not
matter.
What does matter is to learn to trim down requirements to their
essence, so as to get all the necessary functionality in, and then
add in frills and niceties as time permits.
> Once a requirement is documented and prioritized and then there is a
> change to the requirement is a challenge for us to. We keep everything
> in SharePoint, so we have Versions. Traceability is a problem though.
> When was the change made? Why? Who drove the change? Who approves the
> change? How do folks manage this in an Agile environment?
The best way is not to do it. It seems unlikely that SharePoint is
helping you. Neither will traceability be helping, I'd guess.
In "good Agile" you have a single Product Owner who owns all the
decisions. (She may work with others, report to other people.
Doesn't matter: she has the conn on everything.)
Write them on cards. Sort the cards, Tear up the ones that don't
matter, or put them in the History Lunchbox instead of the Current
Lunchbox.
Then, if you must, type everything into (God Save Us) SharePoint or
whatever system outsiders want. Just don't imagine that anyone reads
the stuff.
> Another challenge we have is our software vendor uses their system for
> project and bug tracking, we use WORD, Excel, VISIO, etc and then
> SharePoint for file management.
This seems like roughly four too many systems.
> We use their system too (we upload our documents to their
> "tickets" and add Comments to their tickets as needed), but we
> always have 2 systems of record and we always wonder if they are
> in synch.
I can help you with that: they are not in sync.
> The only way to know is to keep doing audits; which
> takes time. We do not want to use their system 100% as they may
> not always be around (they go out of business, we go with another
> vendor, we bring development in-house, etc).
If you were here with me you would have heard an audible sigh. It
seems to me that you know in your heart that what you are doing is
not working very well. I'd like to hear about your feelings on that
and your thoughts about changing it.
> With Agile, release early and release often makes sense. Are we
> following this by doing 4 weeks Sprints, where at the end of the 4
> weeks the goal is to promote a build to Staging for us to do our UAT?
> Then, when we finish UAT should it go to production? Or, like it does
> now, should we wait for everything to be completed (all 4 sprints in
> this case)? Our plan for Staging was for UAT and then a place for
> internal users to test and see the new features before they go to
> production.
I would push for more like every two weeks. For sure, whatever your
Sprint length, you are supposed to have done, potentially shippable
software ready to go.
> Should we even be trying to be Agile if business and dates will always
> drive a release schedule?
Dates are not a concern. The practices around development and
testing are a concern. From what you've said, it doesn't sound like
you have that stuff in place, but it might be that you just didn't
mention it.
> We are wrapping up a big Release (4 4 week Sprints). We want to make
> changes now for the next big release.
Tell us more about what you really do, day in and day out, that
seems Agile to you. Tell us about your training, and your coaching,
in how to do Agile.
And good luck,
Regards,
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Greg
The more I read your reply I realize we are NOT Agile.
I want us to get there. Where do I start (shrugging with hands up in
the air).?
What's the best resource (book, online, etc) I can get my hands on to
start? I stuided XP Programming 8 years ago; loved it, was never able
to fully implement it where I was though. I have been pushing NUnit on
our development team though they are too busy to implement NUNit and
friends; plus they are 2 years into development so where do they
start? I want TDD, 100% Code Coverage, etc. Where do I start wth a 2
year production application? They are using CruiseControl to do
regualr builds (on a SVN Comitt) .
Greg
capture this though? In a WORD doc?
>
> - Show quoted text -
Greg
offshore, or just some of it? If all, in what way do you think your
current scheme is Agile?
"
in-house.
"Perhaps you could tell us a bit about
> the training and coaching your team has had"
I think we are "Agile like" as we do Sprints, we do a release to
Staging, not Production, every 4 weeks, we pull requirements out of a
future Sprint to manage change/new requirements. We do daily stand
ups, we address Blocks immediately in the stand ups, sometimes
deciding to postpone the requirement if there is a Block that is
taking too much time.
"It
> seems to me that you know in your heart that what you are doing is
> not working very well. I'd like to hear about your feelings on that
> and your thoughts about changing it.
"
to present my suggestions for change to Management in 3 weeks. I am
starting to prepare "my plan" now by doing research. Part of my
research was this post.
Ron Jeffries
wrote:
> User Stories and 3 X 5 cards I like. How do folks electronically
> capture this though? In a WORD doc?
What would capturing it electronically give you?
Ron Jeffries
www.XProgramming.com
If you're not throwing some gravel once in a while,
you're not using the whole road.
LESLIE SCANTLING
Good luck!
> Date: Sun, 28 Nov 2010 11:47:54 -0800
> Subject: [Scrum] Re: Pain Points and GAPS in our SDLC Process
> From: gregte...@gmail.com
> To: scruma...@googlegroups.com
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>