Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So I find myself working for a few weeks in a small team of four, including me. Quite a change from my last job at a 300+ developer shop where I'd been part of the adoption of an agile methodology.
I've been sneakily introducing useful tools like a continuous integration server and am surreptitiously starting test-driven development.
What other agile project management and development practices are appropriate for the smaller shop?
Well, to me, your actual configuration is much more appropriated for Agile than a 300+ developer shop (not really sure how Agile was implemented there, I'd love to hear more about that as scaling to that size requires a very high level of maturity on Agile IMO).
So, my answer would actually be: starting with 4 people, all values and practices are appropriate and valuable. Actually, what Agile methodology did you adopt previously? What practices did you implement? What makes you think they wouldn't be appropriate?
PS: If I may, try to see beyond engineering practices, Agile is not (just) about that (this is especially true for Scrum). Practices such as Test Driven Development, Continuous Integration, etc are nice but they are just a mean, not an end. They won't suffice for a successful Agile implementation. Agile is a business oriented organizational pattern. In other words, technical stuff is not really the best starting point when implementing Scrum, you should start with organizational things.
IMHO all of the development practices are appropriate. In fact, for a long time an agile team was expected to be a small teams (5-9 people). There is an artile of infoq about it.
Also, because you have a small team both communication and collaboration will become easier, so the practices would work even better.
Focus on introducing practices that add the most value to the team.
As the team is small impact of the change will be highly visible, if you work with the team and show improvements then you can go back and add another one - again the one that add the most value to the team.
One of the most important thing is that the projects are approached with an agile mindset, adding tools & techniques in the context of long projects that can't adapt to change & are not highly tuned with the customer won't have the ultimate result that you should be aiming for.
Communal code-review whether or not everyone is on the same site
I think you may want to flip the question around; what agile methods would not be suitable because you are a small team. I am no expert in agile practices, but I can't really think of any that would not be appropriate because of your team size.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm considering running a project using the Agile methodology but the project is roughly 9 months work for 6 developers. Is this project too big to run under as Agile?
Obviously ignoring the risks associated with running the first Agile project on this size.
Thanks,
Mike
Edit
Thanks for all the answers. I have no experience of Agile neither do I have a Scrum Master or anyone with much xp. My original thoughts were how to run an agile project as I haven't architected the system yet. So how do I run a team on a project which doesn't have architecture when the project will last 9-12 months.
Clearly I need to dedicate more time to understanding the principles before I dive in.
No, it's not too big at all. However, your question to me seems to imply a kind of casual approach to methodology choice and perhaps an unfamilarity with Agile generally, or you wouldn't ask it - which Agile methodology were you intending to use? Have you experience in that or in other Agile development approaches? How are you proposing to train peoole in what to do?
You have a typical setup here. 6 devs, room for several iterations.
If you had more developers, I would have recommended you to split them into smaller teams.
Project duration is less important since the approach is iterative and let you develop tbe most useful features first.
The project isn't too big to run as an Agile project.
However, you haven't mentioned any other team members.
Do you have testers and either business users or a BA who can act as a proxy, sat with your developers?
Do you have stakeholders who are prepared to engage and give you regular feedback?
Are your infrastructure team ready to provide you with the environments you'll need for more frequent testing, continuous integration, etc?
Are your architects happy to work in an incremental, evolutionary way?
Do you have a facilitator or coach who can make a safe environment to run retrospectives in?
Are the project board prepared to receive different kinds of reports and metrics?
Are you in a good place to learn and will the people around you make it safe for you to do so?
On an Agile project, the word "team" can be misleading, and the impact of the first Agile project is usually a lot bigger than anyone thinks it will be. Still not too big, though - good luck with it!
The Scrum Guide states:
The optimal size for a Team is seven people, plus or minus two. When
there are fewer than five Team members, there is less interaction and
as a result less productivity gain. What’s more, the Team may
encounter skill constraints during parts of the Sprint and be unable to
deliver a releasable piece of the product. If there are more than nine
members, there is simply too much coordination required.
Keep in mind "Team" in this context is part of the Scrum Team which also includes the Scrum Master and the Product owner, who are just as key. Do you have a person for each of those roles?
Granted, the Scrum Guide may not be a bible, but it's a good starting reference, especially for someone new to Scrum. But I'd say 6 is a good size for your team.
Are you working with a coach or someone on the Scrum Team who is experienced in Scrum? If not, there's a fair chance that you won't understand a number of key concepts. Said a different way, it's difficult to learn scrum from reading about it and trying it. Often teams that take that approach run into barriers, abandon Scrum, then tell people that "Agile doesn't work" because their project failed.
Is this project too big to run under as Agile?
No. Since you seem to be in the Agile and Estimation and Planning phase it, watch this video.
http://www.youtube.com/watch?v=FkWglejhJZM
Mike Cohn (author of Agile Estimation and Planning) talks about a 700 people Scrum Project, divided into roughly 100 Teams, which clearly is a several month project.
Now would you think of your project being big? :)
I would call your project and team as relatively small. Agile methodologies are better for small teams, but the project size doesn't really matter.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm basically familiar with Agile methodology and Scrum.
But what is "Lean Software Development" and "Kanban"?
Is it safe to say that Scrum, Lean and Kanban are implementations of Agile methodology? Or are Lean and Kanban different methodologies?
Do Lean and Kanban provide a skeleton/guideline (like Agile) and leave the implementation to an adjacent set of practices, like XP and Scrum?
Actually, neither Agile nor Lean have a precise definition. Both cases are rather about a set of principles and practices – in the former case, basing on Agile Manifesto, whilst the latter is based on the Toyota Production System adapted to software/IT industry.
I would say that both Lean and Agile are two flavours of the same movement in the software industry – focusing on effective delivery of products which customers actually need (this is a vast generalization though). The difference lies in the ways this goal is achieved.
With Agile, the focus is placed on establishing a well-organized process, which allows frequent delivery and enables easy adjustments to the customers` needs during the course of development. Lean focuses more on limiting "waste" (including work in progress which is considered as one of types of waste) and making the production and delivery workflow as efficient as possible.
It is often that agile and lean approaches are put into the same bucket, so you will find all sorts of mixing – Scrum + Kanban is the most significant example; refer to Scrumban for more information. Unless you talk with an orthodox it shouldn't be a problem if you label Kanban as an Agile method.
To make some order in labels: Agile and Lean are general concepts. Scrum and XP are specific implementations of Agile, while Lean Software Development and Kanban are specific implementations of Lean.
At least this is how people usually perceive them. It is definitely possible to mix different approaches, or single practices thereof, into one method. Scrum+XP or Scrum+Kanban are probably the most popular combinations.
If you want to dig deeper, I can recommend a great mini-book which compares Kanban to Scrum: "Kanban and Scrum – Making the most of both". The eBook in PDF form can be downloaded for free.
Agile expert Mary Poppendieck wrote about the principles of Lean. Find her credentials here.
Instead of me writing a lot about Kanban, please read what Swedish advisors Crisp say about it.
The practices of Lean are quite different from the hands-on, practical tasks that programming-centric XP asks you to do in your project ("Automate everything", "Have tests", "Meet daily"). Value-stream analysis could give you some new insights and conceptual tools with which to reason about business and tasks to do.
Hope this helps navigating the process-speak. Best of luck!
At the risk of irritating purists, and from a practical perspective, Lean is the highest level of abstraction whose principles and (most) practices can be applied across the entire enterprise. Your CEO will understand and buy-in to Lean. In my experience, linking Agile at the tactical level to Lean at the enterprise level makes for a much easier sell to executives.
Kanban in manufacturing is an inventory queue management technique. As applied in knowledge work (not just IT) it is a workflow visualization and queue restriction technique designed to focus teams on the smallest batch of work possible at a time to speed flow. It can be as simple as sticky notes on a whiteboard with tape lines marking off process step left to right. Or there are electronic Kanban tools available (standalone or add-ons to all of the main ALM tools)
Kanban can be easily applied as a tool for Scrum teams simply by treating the kanban board as representing your iteration. You (try to) only allow work onto the board at the beginning of the iteration and it needs to be in the done lane by the end of the iteration. And, using horizontal swimlanes, you can effectively segment the board into sections for planned work in the iteration and the (sadly inevitable) operations support work that interrupts even the most disciplined teams. This make it very clear what work was committed and what snuck into the sprint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I read a lot of books about what practices work well or not in software development.
And I have NEVER heard about methodoly like ITIL or CMMI in any webcast or book or blogs in the development field.
I have heard about these methodologies in my school, and to me it seems to be bureaucratic practices.
However every books on development I've read talk about collaboration, or people over documentation. (Yes, lots of agile books)
So my question is : Does methodologies like ITIL or CMMI have some impact or relation with development or the everyday life of the developer ? And do you have great books or blogs which talk about some good ideas in these metodologies I can use on a development team ?
ITIL is more focused on the infrastructure and support side and not development, so discussion of ITIL is probably more appropriate on the "IT" focused version of StackOverflow that is supposedly in development. As an aside, I take exception with calling that other site "IT" focused as IT encompasses infrastructure, support, and development in most enterprises...probably a good percentage of StackOverflow users are developers in IT departments.
I've worked with CMMI and the Team Software Process (TSP), both products of Watts Humphrey and the Carnegie Mellon Software Engineering Institute. If you are committed to continuous improvement and believe that measurement is at the heart of any continuous improvement, then you will find value in CMMI.
It is very easy to do CMMI (and TSP) wrong or in a way that alienates developers and ultimately ends up as window dressing or something that looks good on a pile of certifications. Look at the development vendors in India...they are miraculously all CMMI level 5. What they don't tell you is that was almost always one small project or team in their organization that worked hard to get the certification, but the repeatable practices are simply not there for 95% of their organization.
The focus on time tracking (clock punching), defect tracking (bug quotas), lines of code (lots of ways to "game" if you are so inclined), and making your process repeatable (making a developer feel like a cog with no freedom to innovate) turn off many developers. <-- note the jaded counter-arguments in parentheses.
The fact remains that 90% of the developers out there (few of which read StackOverflow or any technical blogs/web sites) shoot from the hip and are sorely lacking in self-awareness of where their opportunities to improve reside. For them, the process rigor and opportunity to make incremental improvements in quality through the self-awareness that repetition and measurement facilitate are valuable components of CMMI.
Done right, you get the same benefits from Agile methods like Scrum where again the focus is on repeatable iterations, learning from each iteration, and improving/narrowing in on your goal. It takes a lot of maturity and experience to lead a team in adopting either Agile methods or CMMI and get full value out of them.
Agile is sexy and CMMI is about as far from sexy as you can get, which is why you don't hear about it as much.
Agile adoption tends to be bottom-up: techies stumble upon it and recommend it to management.
ITIL/CMMI tends to be top-down: management stumbles upon it and pushes it down to techies.
That doesn't make one good and the other bad; mostly that affects the language used to describe each approach. And there are plenty of exceptions - people with experience in the trenches who are good at applying CMMI, and managers who grok agile.
Google for "agile CMMI" and you will get many hits. I prefer not to recommend one in particular, because it's an ongoing debate (i.e. some of these folks are just plain wrong).
In my view, the notion of process is certainly a useful idea to have when analyzing day-to-day software development work. The idea that there are some recurring activities, and that these activities are often organized in similar sequences, is a good entry point for asking questions that lead to improvement. You can also get some mileage by asking what is repeatable and under what conditions activities can be called managed.
The error and the excesses begin when magical thinking sets in: "If we just describe (on paper) the Perfect Process and document it accurately, people will follow it and we will get perfect software." It doesn't work that way.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What are the basic steps for Agile software development?
And how you start a new project with agile methodology?
Well OP, there isn't a single documented step-by-step guide for 'agile software development' and any procedure that aligns with the manifesto qualifies as agile
But I also understand that to get started, there has to be a 'hand-holding'/'by-the book' phase of learning. So I'd recommend that
- you take a look at your current development process. Find out the 'waste' activities that sink a lot of time and pick up an agile practice that counters/minimizes the time spent in that activity. e.g. if you're routinely fighting build issues, set up a continous integration server first and set up a stringent check-in pre-screening. Instead of changing everything such that everyone feel lost and alienated,
pick up one practice at a time
Invest about 2-3 weeks with it..get comfortable with it
check if everyone in the team feels that it is helpful. If yes, stick with it, make it part of your new process. Else discard and find and replace with another alternative remedy.
In case your entire team is new to agile, I'd recommend (in order of intensity)
Practices of an Agile Developer (Andy Hunt, Venkat S., thin book, high value-to-page ratio for newbies)
Agile Principles Practices and Patterns (Robert & Micah Martin)
Conduct weekly 'Getting Better' sessions for select practices like TDD (beck, astels, et.all), Refactoring (Fowler, Joshua K.), etc that are bound to have huge payoffs.
a month or so in.. go for the philosophical books like XP Embrace Change - Beck, Lean Books by Poppendieck, Agile S/w Development - Alistair Cockburn, Peopleware - DeMarco, Lister
I'd recommend taking a look at the books listed here
There is a screencast series called Autumn of Agile, that gives an introduction to the agile principles. There are not that many episodes out yet, but the episode plan looks like this:
Agile Values and Practices Overview
Basic OO Design Principles
Design Patterns In Action
Unit Testing Basics
Mock Objects
TDD
Project File/Folder Organization
Source Control Basics
Continuous Integration / Build Automation
Agile Project Planning Principles
Overview of Domain Driven Design Core Concepts
have a look at "Agile Software Development, Principles, Patterns, and Practices" by robert marin. there is a java and a c# version. http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
Henrik Kniberg put together a short PDF, quick and easy to read. You could start by reading it. You'll get the answer to your question and a lot more.
What the best way is to adopt an Agile software development approach very much depends on the situation you are in. Why do you want to adopt Agile? What benefits are most important to you? What are the biggest problems you need to solve? Do you have the resources to do a disruptive all-at-once adoption? Or do you prefer to start with a longer taking, potentially more painful incremental adoption?
I'd highly recommend the book "Agile Adoption Patterns" to help you think about which is the right adoption approach for you. It might also be a good idea to get direct (on site) help from someone who is knowledgable in Agile development - someone who can observe your team, see patterns and antipatterns and contribute his experience on how to deal with them.
One of the practices that I'd always want to adapt as one of the first are iteration retrospectives. Those are vital to the adaption cycle of Agile approaches.
I recommend the article "Creating an Agile Environment" by Gregory S. Smith (http://www.methodsandtools.com/archive/archive.php?id=70) and the video "Transition To Agile Methodology In The Enterprise" (http://www.renewtek.com/index.php?page=agile-methodology-in-the-enterprise)
I'll second Ilja's recommendation for the book: http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
I think the single most valuable piece of the book is the description of what practices to adopt first to achieve certain business values (quality, time to market, ...).
Reviews of the book: http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
Sample Chapter: http://www.informit.com/store/product.aspx?isbn=0321514521#info8
Finally come join an Agile mailing list at groups.yahoo.com either ScrumDevelopment or AgileProjectManagement will suit your needs well.
I've read a lot of Agile books, and the one book I could truly recommend from all those is "The Art of Agile Development" by James Shore.
The best way is to hire a technically-experienced agile coach. Get somebody to work on your team that has done whatever agile method you want to adopt (scrum, xp, crystal, kanban, ... whatever) before. They're going to have to see your working circumstances - and preferably work in the environment to help. Check their references and make sure they really have used it in practice. Lots of wannabees and fakes around.
Having somebody experienced on the team makes all the difference. It's extremely difficult to adopt from just from reading a book. You're trying to change a culture and you can't do that using a checklist or an algorithm. It's a social complexity thing. You're trying to encourage emergent behaviour in a complex system.
If you can't hire an agile coach, find other people on the team or in your department or company that have experience and invite them 'round to see the team. Show them your circumstances and get their opinion.
Different teams will need different pieces of advice - it depends on lots of things including the team members, the kind of technologies you use, the type of business you work in...
Above all else, make contacts with local agilists and learn face-to-face.
You're not agile or not, you're more or less agile.
To start getting more agile from what you're already doing,
visualize more (metrics on screen, visual board, etc)
get more feedback and shorten feedback loops (CI, code metrics, bug metrics, etc)
reduce the amount of simultaneous work in progress (WIP) - i.e., reduce multi-tasking both on individual and team level
If you're able to try something new I'd recommend Kanban. It's the least prescriptive and most flexible agile tool, and you just start by visualizing your work flow and limit your WIP.