aspose file tools*
The moose likes Agile and Other Processes and the fly likes How do we implement Agile in smaller teams with an organisation? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "How do we implement Agile in smaller teams with an organisation?" Watch "How do we implement Agile in smaller teams with an organisation?" New topic
Author

How do we implement Agile in smaller teams with an organisation?

Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

We had once implemented Scrum approach within our team for managing the project completion status. I really don't a lot about the approach but we had this very small meeting everyday to monitor the project progress. So are there any other ways we can include Agile methodologies for different projects within the team? How can we include if there are any?

Also for that matter how can this be leveraged/extended for all the day-to-day activities of a Software developer?


Mohamed Sanaulla | My Blog
Tim Ottinger
author
Ranch Hand

Joined: Jan 26, 2011
Posts: 46

The Programmer Practices card shows several practices you can adopt (though the commercial card is much nicer looking). Any team, agile or not can adopt unit testing practices, and add in continuous integration. Once you have short iterations ending in retrospectives you can find your own way through the rest.

I often recommend starting with the values, then iterations, and then work on building your automated testing practices and teamwork.

A good agile coach can help you to get started in a way that is best for your team (or easiest, depending on which you ask him to do). If one is not available, you might work your way through the Agile In A Flash deck from front to back and have the team choose which practices they have the energy to tackle next.

Good luck!
Tim Ottinger


He writes code. He likes it.
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

There are few practices which would not be able to implement in a large organization- already following its own process. In such cases we would be more concerned with Agility in the smaller teams within the organization working on a certain project whose requirements are fixed and the deadlines fixed as well.
Tim Ottinger
author
Ranch Hand

Joined: Jan 26, 2011
Posts: 46

Is your team's manager in on this? If so, then you can make the changes to install the technical practices, and you can do small iterations within the release schedule. If your manager is not in on this, then it's going to be hard to do much besides add TDD and maybe automated testing. Make sure your manager and nearest neighbors in the process are supportive, and you can do an awful lot.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
It's indeed tougher to change to agile if the rest of the organization hasn't bought into it. But there are still many things you can take out of agile (and of course the deck) that will help your team. First and foremost, the values and principles agile is based on are the best place to start. Shops that do facets of agile without basing their implementation on these principles aren't going to get as much return on the investment.

We often see shortchanging of agile with the very practice you mention. Most shops take on the daily standups (Scrums) and believe they are agile because they've adopted the practice. But the benefits from doing a standup aren't as great, and will even diminish over time to the point where everyone wants to dispense with the meetings, if you don't back them with other changes that go to the core values of agile. That requires a somewhat deeper understanding of things like how increased collaboration within a team positively impacts everything else.

With fixed requirements and fixed dates, you are already put into a challenging situation that can be tough to overcome. You can at least start looking at the planning practices in agile, using short iterations, to get an understanding of what reality is--"how fast do we really develop software?" Doing iterations like this can start giving you improved data that you can use to justify the need for changes to the scope or dates (or resources).

Many of the technical practices can help speed up things over time--but they do take some time to learn and master, so you will take an initial hit in productivity if you adopt them.

Regards,
Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

Tim Ottinger wrote: Is your team's manager in on this? If so, then you can make the changes to install the technical practices, and you can do small iterations within the release schedule. If your manager is not in on this, then it's going to be hard to do much besides add TDD and maybe automated testing. Make sure your manager and nearest neighbors in the process are supportive, and you can do an awful lot.


We had adopted Scrum approach for sometime to see to it that the projects are tracked and finished in time. And it did work out well- We were providing daily updates on the tasks done and plan for the next day. Again as a developer how I could be Agile in my day-to-day work? Automated Testing is already in the process of our development- It comes like a must TDD- I mainly work on the Web app side, so how can I use TDD there? My assumption is that for TDD- one would write JUnit tests and then for those tests one would have to implement my code so that the test cases succeed- Is my assumption right? So I mainly write Selenium based tests, can I use TDD in my development?

Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

Jeff, That's exactly what happened to the Scrum we had adopted. Didn't last long. Most of the times the process which is in place for the development becomes a constraint for the developers- That's where most of the time is spent. Does Agile cause this problem?
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Mohamed Sanaulla wrote:
Again as a developer how I could be Agile in my day-to-day work? Automated Testing is already in the process of our development- It comes like a must TDD- I mainly work on the Web app side, so how can I use TDD there? My assumption is that for TDD- one would write JUnit tests and then for those tests one would have to implement my code so that the test cases succeed- Is my assumption right? So I mainly write Selenium based tests, can I use TDD in my development?


To answer this and your following query, the best way to be agile in your day-to-day work is to collaborate more with your team, and get more feedback about the things you have built and done. Figure out how to make a true team out of your group of people. Embrace retrospectives and continual process improvement. Don't just do a practice because someone says it's good. Understand the "why" of the practice, try the practice, talk about it, improve your use of the practice. Some day you may get to the point where you discover an even better way, and dispense with the practice.

A lot of people say, "You're not agile if you don't X." I think the only really relevant thing you can substitute for X is "regularly reflect and adapt, so that you are continually improving your ability to consistently deliver high-quality software." All the other substitutions are BS: "you're not agile if you don't do standups," for example. The standups themselves aren't what is important--the understanding of (and achievement of) what you hope to accomplish with them is. (They're also a bare minimum for conversation during the day...)

There's no reason you cannot test-drive building your web front-end, using Selenium or other tools. If you are coding some Javascript, there is a way to test-drive a lot of that. Many benefits can accrue from this interest in test-driving web front ends--not the least of which is, "hmm, if I have to figure out how to test this in the web interface; maybe it instead belongs at the server level, where it's both easier to test and a better design."

Some of my thoughts on why standups are usually tedious:
http://agileinaflash.blogspot.com/2009/02/standup-meetings.html
http://langrsoft.com/blog/2007/12/stories-and-tedium-of-daily-standups.html

Regards,
Jeff
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Mohamed Sanaulla wrote:Jeff, That's exactly what happened to the Scrum we had adopted. Didn't last long. Most of the times the process which is in place for the development becomes a constraint for the developers- That's where most of the time is spent. Does Agile cause this problem?


Hi Mohamed,

Agile itself doesn't cause this problem--misapplication of it certainly does (see my previous post, particularly the links I added). And it's a fairly common problem. Scrums weren't meant to be status meetings--they are starting points for daily collaboration. And if you're not really collaborating, then the standups are kind of pointless (may as well just email your project manager with your status and let him send it out).

You also don't need to wait for the standups to collaborate. (It's also another reason why the open workspaces are so much better suited to the high level of collaboration required in agile--if you want to talk about something, just stand up and ask your teammates to discuss it.)

Jeff
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3071
    
  33

Jeff, Thanks a lot for a detailed information. That was really insightful. Will read through the links as well.
Tim Ottinger
author
Ranch Hand

Joined: Jan 26, 2011
Posts: 46

Mohamed Sanaulla wrote:Jeff, That's exactly what happened to the Scrum we had adopted. Didn't last long. Most of the times the process which is in place for the development becomes a constraint for the developers- That's where most of the time is spent. Does Agile cause this problem?


No, but agile can fall prey to organizational issues when its scope is limited or the values are not adopted first. Agile practices are not something you tack to the end of business-as-usual, they are new ways of doing things. People often treat process no better than product, and rush to hack features into it in a shallow way. I don't know exactly your situation, but I suspect that you would have had a different effect if your coaches and managers had managed to touch on the values that make you love programming or helped you become a more team-run group so that you are free to make the changes that make you great.

Please review and consider this, and see if it shows where things went wrong:
http://agileinaflash.blogspot.com/2010/07/agile-success-factors.html

 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How do we implement Agile in smaller teams with an organisation?