As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am looking to introduce an agile method to my boss so that we could hopefully implement it at our work place. I've been doing a lot of research yet I can't find what makes it standout from other agile methods. I am thinking maybe it is the consistent meetings or is it the heavy reliance on artifacts? Please let me know. Thanks!
Look on wikipedia. The scrum agile method is at http://en.wikipedia.org/wiki/Scrum_%28development%29
Here is another stackoverflow question that tells the difference between scrum and extreme programming (XP). Mountain Goat Software also goes into this.
I'd try not to get bogged down in the little differences in the different approaches. It's perfectly legitimate to pick and choose the practices that you think will fit best into your workplace or environment, or the ones that will be easiest to convince your boss (and team) to adopt. You don't have to be dogmatic about just doing SCRUM or XP or whatever.
The key things I would try to implement (but YMMV)
group planning
daily stand ups
time boxed iterations
end of iteration reviews
If I was trying to convince my reluctant boss or team, I'd probably start with daily stand ups. They are low-cost/low-effort, and if done well should help the team gel a little more with understanding what everyone else is doing and what the roadblocks are.
Scrum is focused on how to manage a project, particularly with respect to planning and estimation.
XP (Extreme Programming) is focused on technical excellence and quality within the project, and keeping the cost of change low.
Think of each of them as a toolbox, where one toolbox doesn't build a house. Scrum relies on a low cost of change in order for its measurements of velocity and its estimation off the back of them to be accurate - but it doesn't actually provide the methods for this to work. XP has most of Scrum contained within its practices, though some Scrum techniques like breaking stories into tasks can be useful for teams who are learning.
Even together, you may find that they don't provide quite enough tools for adaptive planning, large-scale organisational change, cultural change, good recruitment practices, and the many other inputs to an Agile team which often get left out of methodologies.
I'd aim for a combination of Scrum with XP, and you might like to look into Lean, Kanban, BDD and Feature Injection while you're at it - there are some useful tools there too.
As for starting, here are my two core practices:
Try to deliver some software (showcase or release every couple of weeks)
Work out why that was hard and what to do about it (retrospectives).
Good luck!
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have graduated from my university almost a year ago. Since then I have worked with many different technologies, such as PHP, JQuery, ASP.NET, C# etc. Recently I have switched to a company where powerbuilder is being used for development.
The problem is that I haven't mastered any of the above languages. I can do stuff with those but when it comes to the complex tasks I often struggle with it because I don't have enough deep knowledge about it. After looking at powerbuilder for a few days I sense that this is going to happen again because most of the application code have been done using some sort of library which requires some advanced level of skill on powerbuilder.
My question is, is it OK for me to work on different technologies without mastering a single one of them?
If you choose to specialise the you are taking an opportunity cost by making yourself unavailable for other types of work. This is good if you can be confident that your chosen specialisation will last for a reasonable length of time. However, you can guarantee (along with death and taxes) that software will change. You will always be required to learn some new framework or approach in order to remain current.
So to avoid finding yourself at an intellectual dead end (are transputers still in use anywhere?) you should adopt a doctrine of constant learning. Learning is usually fun and almost always leads to a joy of discovery of some new tool or design. And never keep this knowledge to yourself (it only has a half-life of 18 months anyway). Share what you have learned with others.
So to answer your question: don't specialise.
According to the Pragmatic Programmer book, one of the tips for a good programmer is:
Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
This means that you constantly have to use, or learn about, new technologies. While becoming a master in one particular technology may be rewarding, technologies come and go, today more quickly than ever. A mastery in one particular programming language, tool or API may make you a guru today, but may mean nothing tomorrow.
IIRC they also recommended developers to master several technologies, but remain versed in many - at least in the sense of having heard about them, played around with them, being able to engage in a conversation about them.
So, I would say yes - specialization is necessary, but this doesn't mean one should ignore domains outside his own.
There is no 'right answer' to this question other than maybe, 'it depends'.
You will find it easier to find better jobs if you specialise, as you call it. I would think of it more as working with a specific language/framework. Further, it is important to solve difficult problems and gain experience, irrespective of the language chosen.
Once you've accepted the above as a truism and specialised, then I would suggest that you branch out and learn new languages. Fortunately, languages become easier to learn when you have more experience.
However, more than anything, you have to look at keeping yourself interested over a long period of time. That is the real key. If you have interest, you will continue learn and gain experience. Maybe that will mean you do something that is not particularly relevant to most jobs, such as writing a language compiler. Or maybe you will find that the rush of working for big clients on big projects is more important than a specific language/framework.
So that's it - just keep interested, and keep learning. And, where possible, build focus in the thing that interests you, as that will make it easier for you to find employment going forward.
It is important to be specialized in at least one programming language/platform, especially early on in your career. By specialized i mean reading a book about it, cover to cover, and having extensive hands on experience developing for it, at work or participating in an open source project.
The idea behind this is that when you specialize in a language, you will learn many concepts that you can carry over to different languages/platforms. e.g: The master of a language can master another with relative ease.
Further on in you career being exposed to many platforms is a good thing, as you start to shift from begin a developer to a developer/architect, and you need to make decisions about which platform to use, the pros and cons of each platform and so no.
So my advice is try to master at least one language, along with its tools and frameworks. After that you can move on to different platforms. It is important to use the right platform for the current project, you will need to determine that case by case, with the assistance of a senior developer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is anyone using Kanban (or scrumban) for the agile management practices? What is your experience with Kanban? How does it work in large complex environments with dependencies on waterfall projects?
I know the BBC use it quite extensively. See David Joyce's blog for more details
http://leanandkanban.wordpress.com/
He has a quite hefty slide deck in there to sift through.
I think the thing to remember about Lean thinking is that you must consider the value stream as a whole. Whilst you can super optimise the development team using techniques such as Kanban, it is more important to incorporate both up stream (Management/Analysis) and downstream (QA/deployment/support) to fully reap the rewards.
Therefore, to ask how does this fit into a Waterfall or complex process (beyond your personal effect), is not quite the right question. What is a more important question is to ask how can I begin to effect the entire value stream. I know this sounds like the beginning of religious Lean zealotry, but it is how you will realise the true value of a lean process.
For example, consider the following scenario for a typical project:
Analysis time: 18 months
Dev time: 9 months
QA & release time: 4 months
Customer adoption and rework: 12 months
Total: 43 months
If by applying Lean to the development process you improve by 100%, ie a development time of 4.5 months, bringing a new total of 38.5 months. You have then only increased the total value stream by just over 10%... insignificant!!
You need to begin to fight the fight and take the Lean thinking to upper management and demonstrate where real success lies... which is in the re-design of the entire process.
Remember Lean is NOT a development process, it can be applied to every aspect of the business.
Some interesting books on how to take this discussion beyond the the development team include;
Lean Thinking
Beyond Budgeting
Throughput Accounting
The Toyota Way
Freedom from Command & Control
Lean Product & Process Development
Implementing Lean Software Development: From concept to cash
Firstly, it is important to realize the problems that Kanban in software development tries to solve:
Multi-tasking / Overload of work.
Kanban addresses these by its
Just-in-time and Queue systems. There
is sufficient in the queue to keep
everyone busy, but not overloaded
(this comes with practice with
estimation and efficient velocity
monitoring). And JIT ensures that
people do not have to multi-task and
hence loose productivity.
Unpredictable downstream releases. If you work in a large software organization, the piece you are developing might just be one in a large juxtaposition of software. Hence, there might be downstream teams that might wait for your feature. Kanban's queue system along with its time-boxed delivery schedules ensure that there is a certain amount of predictability in the releases.
Mostly, other agile practices also attempt to solve similar problems with different techniques.
large complex environments with dependencies on waterfall projects
This makes it hard if you have a dependency on a project that does not follow agile as then your input queue will not be predictable. If a non-agile project depends on you, the problem might be lesser - but you might end up producing more than can be consumed ('muda' in lean terminology). So, ideally you would want all dependant projects at least following some agile practices, if not kanban itself.
A nice article on Kanban, Flow and Cadence can be found here.
Is anyone using Kanban (or scrumban) for the agile management practices?
Yes, I'm using :-)
How does it work in large complex environments with dependencies on waterfall projects?
In our environment we have >500 developers, so it is quite large. My team was the first, which used Kanban, mainly for maintenance work, and now for development. Our daily work was very hard, because the other depending teams were following classic development and management techniques, and they liked (they still do) to push the work and Kanban is about pull.
Our approach was to communicate as much as possible make our work transparent, but due to the reluctance of the environment we were focusing on our internal work. The WIP limit helped us stay focused, and with the visualize workflow we knew who is doing what at the moment.
Our throughput before Kanban was 90% (in other words, when 10 items came in, we delivered only 9), and after Kanban we had 100.4% and it was increasing. As an additional result, other teams started to came by and ask about Kanban, because they liked our results, and wanted to implement their own Kanban system. At the moment I know about 5 teams, which started Kanban in our organization.
HTH,
Zsolt
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What type of client is likely to support XP (Extreme Programming) practices?
I'm working for a company which is doing Agile (not strictly XP, but still applicable), and our client base is exclusively government organizations. Once they saw the results of the agile process at work, even those who had requirements to provide documentation in a Waterfall like manner were more than happy to continue to reap the benefits of the agile process.
And, yes, I agree with vfilby. Your customers should care about the results, not how you achieve them.
If your team achieves great results with a proven track-record, then companies desiring a successful result. If the converse is true, only companies who are wandering blindly will be interested.
There is the odd case where the client will want a certain practices followed. Like a experienced dev manager outsourcing a project to an external firm, or potentially a client who has heard that XP is good in passing but has no real knowledge or experience with it. In the former the experienced consumer will know what he wants and if you do not provide those services they will go elsewhere. If you try to fake it, they will know and be most displeased. The later, it doesn't matter so much as long as they get good results and think it was their own wisdom that brought them forth from the ground.
Either way, it is results that matter.
Now begins my diatribe which so far has inspired much ire:
Would you jeopardize your good practices just to suit a client? If you are staunchly in favour of XP, sell it! If they want you to use a methodology that you strongly disagree with. Tell them that. If you can't come to a consensus, there should be no deal.
Do I tell a baker what grain to use? How hot to have the ovens? Hell no. If I say I want poppy seeds on the buns I don't care how they are put there so long as they are there. Dp I select a baker based on his methods, or on how damn tasty the bread is? Letting a non programmer tell you how to do your craft is just plain bad.
If you are trying to extol the virtues of XP then be upfront, pitch the cost-benefits and ROI. Show them why it is better for them in terms of developer efficiency and defect reduction. If you are working for non-programmers, you are the expert, take the reigns and give advice.
If your team excels at XP and has great results you will have no problem selling any potential client on your practices. Results matter to clients; if you can prove that you consistently produce high quality products within consistent timelines you should have no problem selling your methodology. (with some exceptions that absolutely require waterfall).
Either clients who've already had good results on XP projects.
Or clients who've swallowed the Kool-Aid.
Which arguably makes these clients few and far between :-)
I think it probably takes less convincing than it used to for customers to accept agile development practices, particularly XP, since they are now much more mainstream. Customers who have had positive experiences with agile teams in the past are more likely to buy into these methods. It's probably easier for a smaller customer, or a customer with a smaller problem to accept XP if they have concerns about it. With a skeptical customer, I would suggest starting small and building confidence. And make sure you deliver on your promises!
Almost everyone else seems to be interpreting your question in the context that you are or work for an ISV writing custom software for a client. Is that the situation?
If your question had been something along the lines of what kind of company is likely to adopt XP, then I would say a company who has been burned in the past spending too much time writing developer documentation and designing for reuse only to have to throw it all away as a big waste of time and effort.
The customer has to accept iterative delivery with fixed time, fixed resources, fixed quality (it's working to 100%), and a slightly variable scope, per iteration.
However, it is much more usual that they want to fix time, resources, quality AND scope.
The type of client that is likely to support XP practices,
is one that already understands the benefits and drawbacks of the software production system that XP provides.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The project is poorly defined: we are to write educational software for CS 111 Computer Programming I students focusing on functions. We have 6 student developers with various backgrounds working in Flex. The project has a duration of about 7 weeks. We have very limited face time (30 min per week) and very limited work time (<8 hours per developer per week). We have limited access to the customers (professor of our course, professor of CS 111, students in CS 111).
Our toolset includes Flex Builder, Subversion, and TRAC.
What methodology is best for this project and why? Alternately, what features should be gathered from various methodologies to better suit this situation?
What makes you think any methodology would be successful under these circumstances -- little communication, more requirements than time, and lack of access to customers?
That being said, I would focus on incremental delivery (each iteration should have some few working features), unit testing (all tests pass before check in), tagging of incremental releases (the ability to go back to a working release), and pairing of strong team members with weaker team members to boost the overall productivity of the team. Consider devoting one strong member of the team to integration testing.
Incremental delivery is most important. Showing a working demo of less than what was asked for is always better than showing a non-working prototype.
You could use Agile methodology here but obviously you'll have to adopt it to suit your needs.
For example if you don't have enough access to the real customers that someone with the best understanding of your goals will have to act as a customer proxy. I would also suggest trying to get more access to the customers - almost everyone try to appear more busy then they are and there is usually a way to resolve that obstacle.
Make sure that the limited work time your team have they have at the same time. There could be no Agile approach when you could not work together.
You could definitely use story-based estimations, iterative development process etc.
What is really important is too give every team member a clear and unambiguous understanding of how the Agile process works and what is each person's role in the project. It's very easy to say that you will use SCRUM but unfortunately without real understanding and experience that will not really mean much.
Some advice:
Educate your team members
Get a list of what you would like to deliver if you would not be limited by the time/resources.
Find out what is realistic to deliver given your constraints. That will probably be not much. Don't try to be overly optimistic. Focus on what you could really achieve.
Make sure that your real customers are on board for that.
Use short iterations (1 week or less). Make sure you could deliver fully tested product by the end of each iteration.
Show your work early.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It seems Scrum and Agile tests/assertions are becoming popular this year. For example, Nokia test for Scrum. I don't think it is a good idea to have such tests at all. What do you think?
On the one hand, there are more and more people that claim they are agile, so such a test allows to sort out those in the line of "we're doing XP, we do not comment our code".
But how can we be sure people will understand the question the right way and not answer "well, we have iterations. We often have to extend them a bit to meet our committements, but we do have four weeks long iterations." ?
On the other hand, the link you provided in interesting as it's not the initial version, and it's backed by Jeff Sutherland.
The point is : you cannot sumarize a development methodology with eight questions. Therefore, IMHO, the test alone is interesting, if answered with a correct understanding of the question. It can be helpful for teams that wants to improve. I won't say the same thing for the results that are collected with this test.
This infoQ article says it in a better way: Simple checklists can provide a useful quick-and-dirty assessment. They won't tell you if the practices are actually delivering results.
I just quickly took the test and found that the questions were good questions to ask anyone who claims to be doing Scrum. I'd also ask questions such as:
Do you have an automated build process?
How often does it run?
What happens when the build breaks?
OTOH, a test like this is useful as a self assessment, but I would not 'rate' a team based on a test.
I see Nokia test usable for quick overview.
For further investigation I suggest to use more detailed Scrum Checklist by Henrik Kniberg which is helpfull for coaches and scrum masters to quickly identify gaps in most areas agile team does. Even there are 70 questions, team memebers answer yes/no. We were able to complete this survey in 20 minutes. Especially if you repeat it after few months, you probably will be surprised by answers of your team.
If you need to do deep analyses of agile implementation I suggest to use C*omparative Agilit*y assesment created by Mike Cohn. It helps in relative comparision of your company to the industry. We use it in an enterprise organization with immediate impact on the adaption process quality. Thanks to this is adaption process in this enterprise company much better
See more about Scrum Checklist and Comparative Agility here.