Menu

Implimentation

Do What You Can Now

0

If you haven’t read last weeks post yet I would encourage you to spend some time going through it. In fact, I really would like you to read it over before finishing this post. Usually a writer at this point will tell you that they’ll wait while you go read it. I’m going to be brutally honest with you. I’m not waiting.

I’m not going to pause in my typing for the approximate amount of time it would take to finish the previous post. I’m also not going to try to get some cool web wizardry cooked up to prevent the rest of this post from appearing until after you’ve finished reading that one. It would be relatively pointless since we both know I wrote this whole thing before you looked at the first word. What I am going to do is assume you’ve read it. With that in mind I say I have to ask, what did you do in the last week to move closer to being truly Agile?

More

When to go Agile

0

Change for the sake of change is not a good way to run a company. Truly it’s not even a good way to run a team within a company. Constant unnecessary change will drain a teams energy. It will prevent Agile teams from becoming high-performing.

By that same token never changing is an even bigger failure. The real trick is to do the right amount of change at the right time for the right reasons. This is what we deal with as we try to become more Agile. Every situation is different and I am not going to pretend to have all those answers. What I do know is that there are some general guidelines to help us create an approach to implementing Agile based on how ready the organization may be for change.

More

Fighting OK

0

One of the worst things to have happen at work is for everything to be OK. Last week I read a post over at Managed Agile Development. It got me thinking about the push towards Agile that we are making. We have met with resistance, and some of it is most definitely because things here are OK.

Our development process doesn’t have a huge pain point. Sure, we have some irritation here and there, but nothing really hurts. With nothing causing a large amount friction there’s resistance to change. More

Our Agile Flavor

, 0

Our team is running a little bit Agile in a company that likes requirements up front. We are also doing this as a bottom up shift in thinking.

As previously stated most of the software on our team is in maintenance mode. We are still running our last re-write as a project. It could easily be considered in maintenance, but that has not changed how we work it. Our newest re-write is just getting into full swing. That one is where we are trying hard to run it as an Agile project instead of the mostly stage-gated waterfall that we did before. It remains to be seen how well this works for us. It can be said now that we are using Agile practices on both of these projects.

The project manager and I do have a goal to be as Agile as possible. We aren’t doing this just to make ourselves feel good. We want to deliver the best value to our users that we can as quickly as we can. We are trying to learn from our previous project, which has had some pretty decent re-work, and apply that to this next one. Our conclusion has been to try and run Agile.

More

Trimming Meetings

, , 0

The changes to our estimation process have been a huge hit. The project manager has been nothing but pleased with the new methods. She used to fear estimation meetings and no longer does. The team all has an idea what is happening now when previously they did not. The business feels they have a better handle on what we can get done in any given amount of time. It has been a good fit all around. With this initial success it was time to look at what else in our process could be improved within the limitations we have to endure.

As a by-product of a failed Scrum implementation a few years ago we work in two-week sprints and have daily status meetings. We had a lot of other meetings though. There was a planning meeting that was attended by one developer, one person from SQA, and both business analysts. (In fairness, one of them is the project manager as well.) These meetings were long and painful for everyone involved. They went through the requested work trying to define what exactly it was. They picked what would be done next. They broke it down to tasks and times after which they assigned it to a person. After these meetings would be another meeting we called a kickoff in which the whole team was invited.

More

Gaining Buy-In

, 0

Doing Agile from the bottom up as an internal team is very different then having an external coach brought in by the organization. As our Agile Journey starts it needs prioritization. Not the product backlog, the Agile implementation. Changes have to start small. They are gradual and can only impact this team. For maximum effectiveness benefits are as far-reaching and highly visible as possible. Success or failure is in full view of the organization. Knowledge, planning, passion, and teamwork will stack the deck in favor of success. Success breeds buy-in from above.

To do this alone would be nearly impossible. On a team of four developers I am the most junior. While my overall IT industry experience is on par with the rest of the team, they spent all of it in development roles. For me it has been just under half, with the non-development experience at a different company. Our project manager was let go at the beginning of the year. I was not yet in a position to take on the role and it was given to our lead BA. There was a catch. It become a dual role of lead BA and project manager. This was already a stretch role. The knowledge gained while earning my certification gave authority to my offer of help. The pending maternity leave of the other BA made the need for help painfully obvious.

More

Agile Certification In Use

0

At the end of April I became certified in Agile Practices by the Project Management Institute. There is nothing magic about a certification. What the PMI-ACP does for me is show that I have experience in Agile practices, gained enough book knowledge along the way, took an official Agile Methodologies class, continue to learn more via approved learning methods, and care enough about all of it to spend money showing the accomplishments. While that last one is technically true it is not exactly proven by the certification. In fact, my employer reimbursed me for both the class and test. (In my defense I only learned that this would happen after I committed to making it happen.)

What does matter is what happens next in my professional life. How do I use this in my career?

More