My group is moving to Team Foundation Server soon. Actually, I'm heading up the effort.
One of the things you get to decide is which methodology you're using - Agile, CMMI, etc.
Thing is - I have no idea what methodology we use. By which I mean, we're not actively using one. And I'm not familiar enough with Agile or other methods to know which, if any, happen to apply to the way we're doing.
Is there some default methodology? As in, if we go through some very blunt process (get requirements, code, test, push to QA, have QA test, push to production) is there even a name for it?
And as a bonus, with TFS, what is the penalty for picking the wrong one at the outset? How hard is it to switch gears later if we decide to go Agile or something?
There's no major penalty for switching methodoligies - you just pick a default one when you install, and you can choose the one you'll use for any given project. In fact, it only has to do with how TFS configures the Sharepoint project page initially - you can add whatever you want to your page once it's created, so if you decide to change a project's methodology, it's not difficult to do.
For the two that TFS gives out of the box (Agile and SCCM/Waterfall), it really a question of your process - do you release "early and often", with smaller packages releases as bugs come in, or do you run your projects in large iterations, with a release much more infrequently, but with obvious milestone releases?
A question to ask (though not exactly accurate, but always helps me): Does the product have version numbers that will be meaningful to the end users? For example, many websites are Agile, as they're constantly releasing improvements and patches, and don't often have huge improvement/overhauls, whereas a product like MS Office has a meaningful version number (2003, 2007, etc), which is more likely SCCM.
If you don't have a stated methodology, it's a great time to develop one - decide which release cycle makes sense to you, create a project in each and review what TFS sets up for you automatically - do the progress indicators and Sharepoint pages make sense? Is there anything obvious missing?
If you can't discern a methodology, then you are using an ad-hoc methodology. It may be similar to an existing methodology (by accident). Note however that following a methodology is not the same as being successful. I have seen plenty of methodology heavy projects that failed, and plenty of "seat of the pants" projects be resounding successes (if perhaps in need of a bit of refactoring when the dust settled).
Changing methodologies depends on your culture more than anything. Institutions tend to resist change, and do some individuals. However, it is again situation dependent: if the existing situation is obviously broken, an institution can sometimes make snap changes that surprise everyone.
Some methodologies are "heavier" than others: those are harder to change to or from. Even Test Driven Development is "heavy" in that adopting it after the fact will mean adding a lot of tests to old code. Most real world transitions simply add the testing as files are edited for other reasons. Likewise, moving from TDD to some waterfall style would require a lot of code to be documented in large disused binders.
The most basic method tends to be your iterative or "waterfall method" because you just go from step to step to step. It doesn't seem to be very popular anymore, though.
Related
We've got an Excel spreadsheet floating around right now (globally) at my company to capture various pieces of information about each countries technology usage. The problem is that it goes out, gets changes, but they're never obvious, and often conflicting - and then we have to smash them together. To me, the workbook is no more than a garbage in/garbage out type application waiting to be written.
In a company that has enough staff and knowledge to dedicate to Enterprise projects, for some reason, agile and language/frameworks such as Rails, Grails, etc. are frowned upon. That said, I can't help but think that this is almost a perfect fit for the need, given the scaffolding features for extremely simple implementations of capturing raw fields with only a couple lookups (i.e. a pre-defined category). I'm thinking this would be considered a very appropriate use of these frameworks.
Has anyone worked on these types of quick and dirty apps before in normally large-scale, heavy-handed enterprise environments with success? Any tips for communicating this need/appropriateness to non-technical management?
The only way to get this implemented in a rigid organization is to get this working and demo it -- without approval. It's very hard for management to say no to a finished project.
I work for a really big company & have written many utility apps based on Rails (as well as contributed to some larger Rails projects). That said, the biggest concern is not the quality of the app, but who's going to support/maintain it when you leave or get hit by the bus.
IMHO, The major fear that an enterprise organization has - especially if the application becomes more critical to it's core business - is how to support it. If it doesn't fit into it's neat little box of supported technologies, it's less likely to happen.
Corporations have been bitten by this many times in the past & are cautious when bringing in new technology.
So, if you can drum up more folks to learn Ruby/Rails in your group (or elsewhere in your company), you may be able to make a good case for it. Otherwise, sad to say, your probably better off implementing something on Sharepoint :-(.
If you already have a Java infrastructure, then creating a Grails app will require little to no additional IT ramp up to support and maintain. The support and maintenance cost and effort should be the same as for a Java application (i.e. Grails apps run on Tomcat, use the same JVM, use the same diagnostic/profiling tools, etc.).
In my experience, larger IT organizations have a harder time supporting Ruby when its not already in the toolchain because its a new language, new deployment environment, and requires a considerable amount of support and maintenance ramp up.
I would develop a minimal viable product, then make friends with someone in IT who can help you deploy it into a staging or production environment. Then get a few of the users to hop on board and test it like its a Beta product. After that, open it up to a larger audience.
So as others have said, forgiveness over permission, but be smart about the impact on the IT organization.
Can you please give a methodology that stands to alleviate the disadvantages of waterfall model?
The problem with Waterfall is that it consists of monolithic stages, each building on the previous stage. So the code is developed in one chunk after the entire system has been designed, which in turn happened after all the requirements have been gathered and signed off.
This is problem because any change has to be ratified by a complex procedure and rippled through all the stages. But the lesson of history is: change happens. The requirements are always incomplete, or mis-specified or simply out-of-date by the time we get to coding. Too often design and build proceed on the basis of assumptions which are nullified when the system gets to UAT. This leads to frantic re-work and slippages.
The truth is not many customers are good at the sort of abstract thinking required to envisage a working software software system. And too many IT professionals lack the experience necessary to understand business logic. Waterfall refuses to accept these truth.
The only honest requirement specification is "I'll know it when I see it". So it is crucial to get working software in front of real users as soon as possible. Any methodology which focuses on delivering working software incrementally in short iterations will "alleviate the disadvantages of waterfall model".
Originally that was RAD or DSDM. Then XP tok up the banner. Now there is Agile and related things like Scrum and Kanban.
So why do people persist with the Waterfall method?
There is a common perception that Agile is just a cover for cowboy hackers to ditch all the boring process stuff and get on with what they enjoy most: writing code. The branding of "Extreme Programming" certainly encourage this thought, and, let's be honest, it is not an unfounded allegation. That is, some coders pretend to be agile as an excuse not to plan, design or document. This does not reflect the actual practice of Agile, which require just as much rigour as any other methodolgy.
Also Agile requires a much greater commitment of time from the customer's staff, which many organizations are loath to accept. Also the people footing the bill may be unwilling to empower their junior staff to make decisions. There is an important distinction between Customer and User.
When it comes to outsourcing the waterfall model provides an easy framework for matching deliverables to staged payments. Indeed the contractual aspect maybe stronger than that: in the EU Waterfall is mandated for all projects valued at EUR 100m or more.
Finally, there are projects where Waterfall works well. These projects have knowledge domains which are stable and well-understood by both the customers and the developers.
last word
Despite its failings Waterfall has delivered many projects successfully. This is because hard work, aptitude and integrity are more important than methodology.
The waterfall model was documented in 1970 by a Dr Winston Royce in a paper titled 'Managing the development of large Software Systems'. Basically outlining his ideas on sequential development. His idea was that software could be produced in a similar fashion to an automobile, where the vehicle is pieced together in sequential/linear phases.
This linear approach doesn't really allow for changes in a piece of software once it begins. There is no tight relationship with the end user/client so its harder to outline possible problem areas.
Its worth noting some phases of the waterfall model allow for 'splashback' whereby there is enough time in the development period to go back and make small changes. Time constraints and the amount of work involved and budgets don't really allow for much change if any to be made using this model.
The waterfall model is old, as time goes by software paradigms themselves change. Object Oriented programming is popular, back then it was barely alive. Through the use of the waterfall model its obvious that the flaws have been spotted and this has lead to the alternative development methodologies.
Ok, so now for alternatives. Incremental model is described by Alistair Cockburn(2008) as a staging and scheduling strategy in which various parts are developed at different times or rates and integrated upon completion of that specific part.
Basically incremental looks a lot like this:
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Number of benefits include lifecycle being flexible and allowing for change from the get go.
Working software or rather parts are generated quickly and early on. Code produced is earlier to test and manage due to the small iterations of progress. Not all of the requirements of the system are gathered up front, just an outline. This allows for a quick start, however it might be a disadvantage in some systems as things like the system architecture being supported might be missed.
Iterative on the other hand allows parts of the system to be reworked and revised to improve the system. Time is set aside to allow for this. Iterative does not start with a full specification of requirements. Development is done by specifying and implementing just part of the software. Software is reviewed in order to identify further requirements.This is more of a top down approach. Disadvantages with this methodology are making sure all the iterations are compatible. As each new iteration is approved, developers may employ a technique known as backwards engineering, which is a systematic review and check procedure to make sure each new iteration is compatible with previous ones.A major benefit with the constant iterations is that the client is kept in the loop and the final product should meet the requirements.
Iterative approach diagram.
Other methodologies include Prototyping. Evolutionary and Throwaway. These are also deemed as more of a top down approach. Both process are borrowed from engineering.In engineering it is common to construct scale models of objects to be built. Building models allows the engineer to test certain aspects of the design. The software development prototyping methodology provides the same ideology. Prototyping is not seen as a standalone, complete development methodology but rather an approach to handling selected portions of a larger, more traditional development methodology.
Throwaway Prototyping - Throwaway prototyping does not preserve the prototype that has been developed. In throwaway prototyping there is never any intention to convert the prototype into a working system. Instead the prototype is developed quickly to demonstrate some aspect of a system design that is unclear. It can also be developed to help users or clients decide between different features or interface characteristics. Once any problems or uncertainty has been addressed the prototype can be ‘thrown away’ and the principles learned used in the design and documentation of the actual product.
Evolutionary Prototyping - In Evolutionary prototyping you begin by modeling parts of the target system and if the prototyping process is successful you evolve the rest of the system from those parts. One key aspect of this approach is that the prototype becomes the actual production system. This process allows for difficult parts of the system to be modeled successfully in prototypes and dealt with early on in a project.
Other areas to look into will include Agile-> SCRUM, Extreme programming, Paired programming etc.
Tried to keep it short but people write books on this sort of stuff and there is so much to discuss.
Might be worth having a look at:
Incremental and Iterative
The alternative to the waterfall method is "doing it the correct way".
Waterfall seems to make sense if you are on a factory floor assembly line. But I've never seen it work as part of the design process...and sofware development is ALL a design process. And so the waterfall method never really works in the sense that it doesn't help facilitate the creation of high quality product, but rather focuses on process. Process can be great, but what's the point if the product it produces is second rate?
Kanban and Scrum are two of the most commonly used alternatives to Waterfall. I tried to give a good overview and comparison of the different SDLC approaches.
Waterfall relies heavily on massive monolithic phases as mentioned by APC. This is a huge weak point because trying to determine the end product from the start is a fruitless endeavor.
Kanban is slightly cowboy, but I find if you couple it with standups it certainly still has it's place.
Scrum is great for putting pressure on the team and getting ownership on tickets. I've found most places have been going with this one but the downfall of it is some people go overboard with having meetings for everything. Sprint planning meetings, sprint kickoff meetings, daily standup meetings that last 1 hour with 20+ people present, demo meetings, and then finally the post-mortem.
Remember that agile is only as good as you make it and you can easily sink any methodology if you go wild with unrestrained meetings which aren't adding value. Keep it as lean as you can without it being chaotic.
From the top of my head, I can think of ways to palliate the shortcomings of the waterfall model:
Have the coder concentrate on automating the process itself. Automate the transitions between one step and another, so that changes will flow more or less automatically.
Make the process more bidirectional. One principal characteristic in the waterfall model is that changes flow from top to bottom. This is a unidirectional process, and that is part of the problem.
Another thing which would help is (as someone mentioned in an earlier answer) is for the developer to gain a better understanding of the business logic involved, and of what the customer wants, and for the customer to gain knowledge about the characteristics of the development process.
Here are some links about Waterfall model:
http://www.cs.odu.edu/~zeil/cs451/Lectures/01overview/process2/process2_htsu2.html
http://www.buzzle.com/editorials/3-13-2005-67039.asp
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
Lately I have seen our development team getting dangerously close to the 'second system syndrome' type ideas while we are planning the next version of our product. While I'm all for making improvements and undoing some of the mistakes of our past, I would hate to see us stuck in an endless loop of rewriting and never launching anything.
Is there a good design / development method that lends itself to building a better version 2.0 while avoiding second system scenarios?
I have experience the second system syndrome from both sides as a customer/sponsor and part of a development team.
A root cause for problems is when the team latches on to an Utopian vision of version 2, such as the desire to make the new software "flexible". In this scenario everything is abstracted to the nth degree. For example, instead of data objects that represent real-world entities a generic "item" object is created that can represent anything. One flawed idea is that we can build in so much flexibility into the software to anticipate future needs, that non-programmers will be able to just configure new capabilities. Often one goal such as "flexibility" overshadows the effort to a point that the resulting software doesn't work.
A balanced practical consideration of usability, performance, scalability, features, maintainability, and flexibility goals can bring the team back to earth. "It would be great if..." should be prohibited from the vocabulary of the team. The Scrum backlog is a good tool and the team should be heard saying often... "Let's backlog that...we don't need that for version 2."
"I would hate to see us stuck in an endless loop of rewriting and never launching anything."
Which is why people use Scrum.
Define a backlog of things to build.
Prioritize, so that things which lead to a release are first. Things which should be fixed are second.
Execute sprints to get to the release. Execute a release sprint.
Get someone who has written at least three systems to lead the project.
Try to focus on short delivery cycles, i.e. force yourself to deliver something tangible and useful to the users every few weeks or month. Prioritise the tasks based on their value to the customer. This way you always have a usable, functional application with satisfied users, while under the hood you can refactor the architecture in small steps if you wish (and if you can justify the need for it - that is, towards management / the customers, not just teammates!).
It helps a lot if you have a stable build process with a good suite of automatic (unit / integration) tests.
Agile development methods like Scrum do this, and they are warmly recommended. But of course it is not always easy or even possible to adapt such a method in your team. Even if you can't, you can still take elements of it and apply it to your project's benefit (maybe without even mentioning the words "agile" or "Scrum" publicly ;-)
Make sure you document the requirements as well as possible. While obviously you need to also manage what gets into the requirements to avoid over-designing, having a fixed scope helps prevent developers from running off with ideas or gold-plating what needs to be done and it helps keep management or clients from introducing scope creep. Define all requirements and how scope changes will be addressed.
I'm all for short development cycles (make sure you're writing tests) and agile methodology, but neither of those is a shield against second syndrome system. In some ways it's easier to keep adding on feature after feature if you're working in short sprints without stopping to look at the overall picture. Use agile practices to build the simplest thing that works, then keep adding your other requirements as simply as possible. Remember YAGNI, because when you build a system a second time, that's when you're most likely to build something you're sure you'll need at some point, something that will make the system "extensible" so there never has to be a third build. It's the best of intentions, but the road to hell and all that.
You can't get close to second system syndrome. Either you're in it, or you're away from it. You'll know when you're in it, but only after wasting a lot of resources.
Tips are: know about it (so basically we got that covered already). It's invaluable information to know what a "second system" is, and even more to have some experience with that. I think we all have some experience with that, hopefully benign.
That knowledge will often make you think twice and you'll find a solution without venturing into second-system limbo.
PS: Also know how to use your current system, that includes, maybe documented solutions, and other documentation.
Focusing on the system architecture should help e.g.
Having documented interfaces which support "loose coupling" between sub-systems
Having documented design decisions (avoid re-hashing previously beaten paths)
Hence, without going for an all out swap, the current system can be "upgraded" with more appropriate interfaces to help future growth.
Another good way to focus: assign a $$$ figure to each feature and prioritize accordingly ;-)
Anyhow, just my 2cents
I up-voted S. Lott's answer and would like to add some more suggestions:
Deliver a working product to your customer as frequently as possible. Iterations lasting between a few weeks and 2 months are ideal. Agile methodologies, such as Scrum, lend themselves well to this.
Use FogBugz for feature and bug tracking. Its features are very practical for agile projects. FogBugz allows easy prioritization according to releases and priorities. If your team enters their estimated levels of effort for each task, you can also use this to calculate reasonable ship dates.
Prioritize which features you will develop according to the 80/20 rule (20 percent of the features will be used 80 percent of the time) and the most bang for the buck. This helps keep the system as simple as possible, helps prevent feature bloat, and saves development and testing time.
Give similar thought to both new features and bugs when you determine the priority of an issue. One point of the Joel Test is "Do you fix bugs before writing new code?". In most shops this doesn't happen, but do not make debugging the system an afterthought. Also, keep a working copy of the old system to compare against when bugs are found on the new system.
Also factor in the level of effort required to maintain, and if necessary rewrite, existing code. If you have not already done this, give the team some time to code review whole files that they find troublesome to change. If the system's code was difficult to maintain the first time, this will only get worse and cause your team to spend more time on new features down the road.
It can never be avoided at its entirety. But being cautious could alleviate the problem.
You should formulate some thumb rule based on the vital parameters (scarcest resource) that define the success of the system. For example, reducing potential number of bugs might directly decrease operational cost (potential service calls to support center). But this might not be the case in every other systems. Another example, scarce use of CPU, memory and other resources might be beneficial in some cases but there could be environments where they could be available in abundant.
So simply to avoid "temptations", identify the scarcest resource (time, effort, money$ etc) and consider implementing only those that exceed threshold value.[f(s1,s2...) > threshold]
Despite the iterative development, I would emphasize on how technical debts are handled.
Links that are related to this:
Tech Debts: Effort Vs Time
Tech Debt Quadrant
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 3 years ago.
Improve this question
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Use Source Control for EVERYTHING
Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
Use bug tracking - Bugzilla or FogBugz if you can afford it.
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.
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 3 years ago.
Improve this question
I am quite new to Lean/Kanban, but have poured over online resources over the last few weeks and have come up with a question that I haven't found a good answer for. Lean/Kanban seems otherwise such a good fit for our company, who is already using Scrum, but have reached some limitations inside that methodology. I hope someone here can give me a good idea.
As I see it, one of the biggest advantages of Scrum over Waterfall is the use of sprints. By having everything ready every 14 days you get short feedback cycles and can release often. However, as I have understood from reading about Lean, there are some costs associated with this (for example, time spent in sprint planning meetings, team commitment meetings & some problems with finding something useful for everyone at the end of the sprints).
Lean/Kanban will remove these wastes, but only at the cost of not being able to release every 14 days. Or have I missed an important point? For, in Kanban, how can you work on new development tasks and release at the same time? How do you make sure you don't ship something that is only halfway done? And how can you test it properly?
My best "solutions/ideas" so far are:
Don't release often and allow the waste associated with running out of new development tasks. Not really a solution to the question asked though.
Develop in branches and then merge into the main trunk. Makes you have to support at least two branches continuously internally.
Use some smart automatic labelling system to automatically build only certain finished tasks and not others.
As a summary, my question is: When you use Lean/Kanban, can you release often without introducing waste? Or is release often not part of Lean/Kanban?
Additional info specific to my company:
We use Team Foundation System & Source Control and have previously had some bad experiences in regards to branching and merging. Could this be solved simply by bringing in some expertise in this area?
The problem you describe seems more a source control program -- how to separate done features from features in-progress, than about Kanban. You seem to put a heavy penalty on running many branches -- which is the case for source control systems not based around the idea of multiple branches. On Distributed Source Control systems, such as GIT and Mercury, everything is a branch, and having them and working with them is lightweight.
I assume you read this blog about Kanban vs SCRUM, and the associated practical guide?
And, in answer to your question, yes, you can release often with Kanban.
You need to understand pull systems, which is what Kanban is designed to manage.
A customer (or product owner or similar) request for a feature in the running system is what triggers the process.
The request is a signal that goes to deployment. Deployment look for a tested item with properties that match the request. If none is there, you write the tests and look at development if there is a development slot that can be used to implement something that fulfils the test. When development has done its development (maybe looking for a suitable analysis first and so on), the test does its test, and deployment deploys.
The requests going backwards through the system are permissions to start working. As soon as the request has arrived, this triggers a lot of activity, where each activity should be completed as quickly as possible. There you have your turbo deployment.
Just like the request for a car goes to the dealer who looks in the ship who signals to the car factory, who signals to the suppliers.
Kanban is not about pushing requests through a system. It is about pulling functionality out of the system in exchange for a request that enters via the last step.
The team I manage uses Kanban and we release around every two weeks. If you're strict about what gets integrated into your mainline code branch (tests passing, customer approved, etc.), Kanban allows you to release whenever you want. You need to make sure that the stories moving through your system aren't co-dependent in order to do this, but on my team that's usually not a problem - a large part of our work involves maintenance, which consists of several unrelated bug fixes / features per release.
The way we handled weekly releases on a sustained engineering project that used Kanban was to implement a branching strategy. The devs worked in a sandbox branch, and made one checkin per work item. Our testers would test the work item in the sandbox; if it passed the regression tests the checkin would be migrated to our release branch. We locked the release branch from noon Monday until the release went out (usually by Wednesday, occasionally by Thursday, the drop dead date was Friday), and re-ran the regression tests for all migrated checkins as well as integration tests for the product, dropping a release once all of the tests passed.
This strategy let devs continually be working on issues without being frozen out of their branch during the release process. It also let them work on issues that took more than a week to resolve; if it wasn't checked in and tested/approved it didn't get migrated.
If I were running Kanban for a new version of a project, I'd use a similar strategy but group all related checkins as a 'feature', migrating a feature en masse to the release branch once the feature was done and then performing additional unit/integration/acceptance/regression testing in the release branch before dropping a release with that feature. Note that a key concept of Kanban is limiting work in progress, so I might restrict my team to work on one feature at a time (this would probably be several work items/user stories).
There's more to this than just source control, but your choice of TFS is going to limit you. When the Burton project was conceived back in 2004, Microsoft wasn't paying attention to Agile, much less Lean. It's going to be your weakest mechanical link for some time. Your hackles should have been raised by CodePlex's own adoption of Mercurial after having been offered to the Microsoft community as the poster child of TFS implementation.
A more salient issue here is Work Design. It encompasses the order that you choose to implement features (work schedule), as well as prioritization and cost of delay, and the shape and size of work items.
Scrum is commonly interpreted to say that non-technical "Product Owners" can determine work schedule based solely on their own concerns. If you follow this path, you're going to incur a lot waste by not taking the opportunities to do work together that belongs together. Work that belongs together can't just be determined by Product Owner wishes. Technical and workforce (skills) opportunities must also be taken into consideration.
For work to be done in the most productive way, the work itself has to be designed that way. This means that in a Lan Product Development team, decisions are made not by a non-technical worker, but by what Toyota calls someone of "Towering Technical Competence" who is close to the product, close to the customers, and close to the team.
This role is a stark contrast to Scrum's proposition. A Chief Engineer on a Lean team is himself (or herself) the voice of the customer, and the role of Product Owner is unnecessary.
Scrum's "Product Owner" is a recognition of an under-developed role in software development organizations, but it's far from a sustainable solution that consistently avoids waste. The role of "Software Architect" is often insufficient as well, as in some developer sub-cultures, the architect has become far too removed from the work.
Your issues of continuous deployment are only partially addressed with technology and tools. Look also to organizational issues, and perhaps give some thought to Scrum's purpose as a transitional approach from waterfall rather than one that can serve your organization indefinitely.
For source control I'd highly recommend Perforce. It makes branching and integrating changes from other branches relatively straightforward, and provides the best interface for source control that I've seen so far.
Continuous integration helps as well - i.e. lots of small, more than daily commits, instead of huge and potentially challenging merges. Tools like CruiseControl can help highlight when the source gets broken by a bad commit. Also, if everyone makes many small changes then conflicting changes will be rare.
I'd also advice not to try to follow things like lean, scrum, kanban & co. too closely. Just solve the problems yourself, looking to these ideas for guidance rather than instruction. The specifics of your problems will more than likely require some flexibility for the best management.
How we do it:
We have a pipeline with the following stages
Backlog
TODO
In progress (Develop and quick testing)
Code review
Test (Rigorous testing)
Integration test and general acceptance tests
Deploy
Each story is developed as a branch based on the latest version to leave the Deploy stage. They are then integrated as part of preparing the integration test.
QA pulls from the code review stage and can prepare releases at any pace the want. I think we have a pace of roughly one release every week.
By removing the "master" branch from git and not doing any merge before the code review stage we've made sure that there is no possibility to "sneak" code into releases. Which, as an interesting by-product, has forced us to visualize a lot of the work that used to be hidden.