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
Our IT manager is pushing for ITIL, I'm only loosely familiar with it and wanted to know if ITIL fits into an Agile work-cycle well?
From my initial impression I would assume no, mainly because what our manager is proposing is to put timelines against everything, stating SLA's to the business that "high priority tasks must be completed in x hours" etc... which we get penalised as developers if we do not meet these SLA's.
If anything I'd prefer a negotiation strategy where timelines are based on agile methods of velocity and story points to negotiate an expected timeframe to end users.
We have our agile development practices in place, test driven development, continuous integration, there's areas for improvement but we're working on it.
What are others experiences with ITIL and Agile methods working together?
In my company ITIL framework is used for service delivery (production and incident support). For this SLAs are appropriate as if you are say losing customers/money per hour then it is expected that business should have some indication of when things will be fixed. It is not directly related to development methodology. Only if you decide that an emergency hotfix is required and approved then some development may be done. But hotfixes are usually very small and targeted to fix a defect and shouldn't cause any issues with agile methodology. New requirements are never done as hotfix change and are taken in normal dev/test/release process.
That doesn't look good at all, if that's the case, it really doesn't fit agile at all.
I'm suspicious if ITIL really calls for that, specially since "high priority tasks must be completed in x hours" goes beyond not fitting agile, it doesn't fit software development i.e. all tasks aren't born equal.
update:
So would you say that normal development processes can be exempt from ITIL methodologies and have ITIL purely concentrate on the infrastructure/incident support areas?
I don't think this is mutually exclusive. While it might be the case that ITIL isn't applicable in how you manage the team, it doesn't mean there aren't valid areas of it that affect what you develop.
Development needs to include considerations in the design/product that are required by infraestructure / support, and such may relate to practices suggested in ITIL.
Maybe a more appropriate question would be: are management aspects/practices of ITIL applicable to management of software development? which I don't know, but suspect is addressed specially in ITIL. At least I know that ITIL 3 introduced changes that relate to Enterprise Architecture practices, that are definitely compatible with agile (in fact are enablers) --- but at least those are far from anything related to fixed estimations / task tracking / dev response times.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
Firstly, I'm aware there is a UX stackexchange, but I'm a UX designer trying to get more of a dev's perspective! How can the UX design activity work well with a team of developers and testers trying to work in an Agile way? There seems to be reluctance to do any (UX) design up front, and to only engage users after something has been built, rather than prototyping and testing with users before making production-quality code.
The basic theory behind agile is that there should be close collaboration between the development team and the customer throughout the development cycle, and that the team has all of the skills needed to succeed.
In your case, the UX designer skillset should be represented on the team, and conversations with the customer about UX concerns should take place alongside conversations about functionality.
So, the explicit answer to "How can the UX design activity work well with a team of developers and testers trying to work in an Agile way?" is "In an agile way, of course!" You need to work on the same stories as the developers. Don't try to create a UX design all at once. Let it emerge over time as the stories are developed, just like the functionality. As the developers are working with the customer to understand the functionality of each story, you need to be present and discussing UX concepts. Functionality and UX should evolve together, so the developers always know both what the software should do and how it should look and feel to the user.
The developers have learned that big design up front is a bad thing; the same goes for UX.
A key aspect of Agile is responding to change over following a plan.
Creating a detailed UX design up front works brilliantly as long as the requirements are unchanging and there are no technical problems encountered that require changes to be made. Agile is all about handling these kinds of changes.
The best way for a UX designer to work in an Agile way is to think of it as a 'just in time' process. What is the best way for you to produce good designs but to do the work at the latest possible time that is practical?
In this way if a change does occur (for example there is change in priorities and you have to quickly focus on other work) then you are best positioned to quickly adapt.
As you can probably tell this isn't a one-size-fits-all solution. Each team needs to explore how they fit design and developement together. With some teams they might have the designer pairing with the developer and work on the design and development at the same time. Other teams might do their designs a few weeks ahead and run them by the users so that they are approved and ready by the time development starts. There are no hard and fast rules here, it is about doing that which the team finds to be most effective.
It is all about discovering the best compromise between doing detailed up front preparation and being able to respond to late changes.
You should try faster methods, as paper wireframing or balsamiq mockups which gives you a very good idea of what the system will look like, so you can test with real users and you are able to make an 'on time' delivery between sprints.
It is very important to discover what the user needs,or to be more accurate to see if they get the idea of your development before It's built.
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
Everyone is talking about Agile and how good this is. There are several advantages and disadvantages of Agile. I have studied them theoretically. Since there are experts here who have worked in many projects I want to know real two-two scenarios where Agile is unsuitable and suitable. Thanks
If it is possible to do agile well, then i believe that is always a good thing. If it is not possible to do it well, then i believe that it can be harmful. Not because there's anything intrinsically hazardous about agile, but because it would mean using a dysfunctional process.
So, agile is unsuitable when the conditions for doing it well do not exist.
Some things that could scupper the adoption of agile:
Team members do not understand the process, and do not have either the time or the inclination to learn it
Team members do not have the experience or maturity to assume more control over their own process
Management requires detailed long-term plans as a deliverable
The customer is unwilling to provide feedback on incremental releases before the final ship
There is a high churn of members in the team
The technology in use does not permit a build and test cycle of a useful length (i've done agile with a three-hour build and test cycle; this was very painful but just about doable), or does not permit it at all
The problem domain does not admit incremental development of a solution (i'm not sure if this is ever true; the nearest i've come to this is when dealing with cryptography, where the thing either works completely or doesn't work at all)
To some extent, these can be remedied. An uninformed or inexperienced team can be shepherded by a cadre of informed or experienced members. Team leadership can write a long-term plan, then let the team ignore it and hope that delivering working code will pacify management. Business analysts or QA can act as a proxy customer for providing feedback on incremental releases. Branching strategies and build servers can be used to decouple build-and-test from commit and merge. These remedies are certainly not guaranteed to succeed, though, and if the problem remains insuperable, agile will not be succesful.
Agile may be unsuitable when:
it threatens to expose overgrown management (some positions suddenly become clearly superflous)
people actually don't want to have fun and do creative things, preffering 9-17 mode of mundane work (maintenance of legacy crappy software that just cannot wait to be disposed of)
politics rather than professionalism run the company
Human Resources run the company (Agile is about humans, HR treats them as things)
the customer expects that you will figure out what he needs for him (Agile will make you asking him questions that he doesn't want to answer)
Agile is expected to be a magic wand that will solve problems without anyone changing their habits (another buzzword, a fad)
development is spread across multiple locations far away from each other, in different time zones (communication suffers)
you have a pointy-haired boss ;)
or in general:
it is misunderstood
organization is devoured with serious patologies
no one actually wants it
I worked with many different teams trying to move to agile. Some succeeding, other which did not succeed. Based on my experience, I can say that:
Moving to agile is suitable when the software creators want to improve quality of their product(s) (whatever its mean in their context) so badly that they are even ready to work as a team to achieve it.
Moving to agile is not suitable when everybody is happy with the current quality level and/or do not want to work as a team.
Sort answer:
agile is suitable, when IT company is making its own product. e.g. visual studio is made in agile way couple of years. And you can see much better "idea to delivery time".
Agile is not suitable for Internet Banking. Another example is client based in US and dev team or its part in azia. The time delay makes things complicated.
Long answer:
First, if you want to run an agile project, your management should understand it and processes in your company should embrace it. If you try to workaround them, you will fail. See how management and internal processes are important here: https://www.youtube.com/watch?v=4u5N00ApR_k It's more important that the management and team leads understand agile processes than the programmers. Usually, opposite is true.
Second, your client's management and processes should embrace agile processes. A bank or financial institution will never sign an agile contract. Their processes requires deep planning and approval at multiple levels. See how clients misunderstanding of agile can cause a fail: https://www.youtube.com/watch?v=lAf3q13uUpE
I completely agree with Tom Anderson, that the circumstances are more important that the type of project itself. For example, if you have signed fixed contract (either because of your management, or a client), you probably have detailed requirements. If you have detailed requirements, you wont run scrum but "SCRUM BUT". It's against agile philosophy.
It may happen that the project is not suitable for neither agile, nor waterfall.
Sometimes it's better to use agile internally having Product Owner role assigned to somebody from your company, who understand the domain best.
Suitability and Unsuitability of Agile methods?
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 haven't yet started learning either of the two, but I was wondering whether any of you use Agile methodologies to implement SOA?
Thank you
So the question is: Are SOA and Agile friends or foes?
In summary, Service Oriented Architecture (SOA) and Agile software development both help companies become more flexible and better align business and IT. As a result, many have noted that SOA and Agile seem like a natural fit.
SOA introduces a controlled environment in which changes are accommodated in support of Agile processes, where quality, efficiency and productivity are increased through the appliance of design patterns, standards and governance procedures. Design patterns like service reusability, composability and abstraction, to cite a few, are leveraged to provide flexible and adaptable ecosystems. Agile methods also enable the lifecycle to be more incremental and interactive, allowing the business to get/give faster feedback from/to IT. They both support the continuous business-IT cycle that is needed to allow businesses to set up strategies aligned with IT. --What does SOA brings to Agile? Or Agile to SOA?
Explanation
As you can see in the SOA Manifesto 2009 and Agile Manifesto 2001, there are plenty of common values, such as Agility, Flexibility, To see changes as oportunities and a lot more. Some see SOA as an evolution of Agile, due to Cloud Computing [2008], Web Services [2004] and so on. These people, who have written the manifestos, were unhappy with Waterfall Model because the clients were unhappy due the limited software delivered. The clients couldn't change the requirements without burocracy and sometimes they only knew what they want or need in the middle of the process, in this time a contract had been already signed. It looked like Fred Brooks, Jr said "Plan to throw one [implementation] away; You will, anyhow!".
So the people started to make things in Agile way. And it brought happiness to clients. They, somehow, started to be satisfied by the software and the software was more accurate than ever, with minor bugs and according to the requirements.
With the distributed systems's BOOM!, in my opnion started with Google, some people start develop things on the internet, such as public or private web services and external API, and the good practice of SOA was buzz word. They wrote the manifesto and it became a major architectural design.
Notes
Waterfall isn't bad or wrong! For some people like NASA, it still good, and it works well for important software that specs won't change.
There are much more architectural design patterns, such as Layers and so on. What you need to know is if this pattern fit into your project or not. Maybe SOA won't fit.
Futhermore, There is no silver bullet!
Working full time with SOA implementations, I have some experience regarding this.
You can use different methodologies to implement SOA into an organisation. I've seen no attempt to go in and in one single project remake the entire enterprise integration design to SOA. Rather, this will happend step by step once business requirements emerge or changes.
Often each sub project in a SOA implementation is rather small - often too small to divide into SCRUM sprints with production releases.
In many ways the Waterfall method is usually conceptually the easiest method to implement SOA. The specs of a service WILL CHANGE over time, but there is no way this can be planned into, say 6 months intervalls, since it's very much driven by business requirement changes or influenced by upgrades/exchanges of enterprise information systems.
However, when the design phase is done and specs + technology pattern is decided, there might be a decent amount of changes of the design spec. in a projects once the implementation phase has started. It is usually the case, from my experience, that once started to flip the stones, old and unknown thigns crawls up that requries changes. A more iterative approach will usually be cheaper than strict waterfall - however not necessairly an agile approach.
Another important factor to decide upon the methodology is the way projects are financed and setup. An agile approach might get better overall result/cash ratio, but that is only if your organisation can cope with agile methods. If you are working as internal contractors to enable SOA for some busines requirement, which I am used to, then a project plan might be setup, a cost estimate and a strict time schedule with responsibiltites. It's rather hard to hold such as schedule for every single project with an agile approach, specifically, it's hard to give clear cost estimates for small-medium SOA projects.
For larger SOA projects, delivered to a single owner, I've succesfully used SCRUM and really recommend it.
Yes, we do use Agile methodology to implement SOA powered projects. But there's no objection to not to use Agile methodology. I guess in some specific projects e.g. Defense Ministry or Highly Risk projects where Agile are not allowed due of hard control SOA used too. Because this terms are orthogonal.
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 10 years ago.
Improve this question
What does the "self organizing" in "self organizing Scrum team" mean?
See this article for a good explanation. This quote explains the heart of it:
Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.
The team approaches a project, and, based on the project at hand, decides how best to allocate its resources to take advantage of each team member's various strengths.
What does the "self organizing" in "self organizing Scrum team" mean?
It means this: No one – not even the ScrumMaster - tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team’s overall efficiency and effectiveness.
Reference: Scrum Guide
A self-organising team is one in which every member of the team is working towards some shared goal. Team members collaborate to reach the goal, valuing the team's output over their own individual productivity.
A self-organizing team tends to be:
trusting of each other's motives and motivation
helpful, respectful, communicative and transparent
collaborative with other teams
interested in delivery and feedback
goal-focused instead of productivity-focused.
The project manager's roles in a self-organising team tend to be:
making sure that the team has people with sufficient skills to succeed
helping them be aware of and understand information coming from elsewhere in the company
reporting the team's progress, successes, risks and obstacles to other audiences
getting stuff out of the team's way wherever possible (see Servant Leadership).
A self-organizing team is usually pretty good at getting things done, blasting through obstacles, communicating issues outside of their control and generally provides a great project experience for anyone using them. See also: Forming, Storming, Norming and Performing - you're looking for that last one.
It’s a flexible, responsive team that is allowed to make important decisions on its own in a preset framework. Usually, the management decides on the goals and overall deadlines for a project. Then it's up to the team to find the best ways to attain these goals, distribute tasks among the members, plan and evaluate their own work at the interim deadlines they set. Team leadership is not set in stone. Usually, the Scrum master changes regularly, so that each team member has a chance to try this role.
The main aim of such teams is to encourage the self-actualization of every worker. When team members can make a difference, they feel inner responsibility and motivation to perform. This way, self-organization promotes innovation and a good team morale, both of which look like solid benefits. By the way, we recently published a blog post explaining the benefits of the concept in more detail. You can check it out here, if you are interested.
A self-organizing team in Self
organize scrum team means each and
every team member is responsible for
their individual module, Scrum master
role is minimal/existed in the team.
Self organizing scrum team means low
ceremony and trying to work as a
collective whole so titles mean
little.
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
RUP in the dialogue with Scrum
There is a relation between Agile and RUP. Actually I though that Agile development was a type of RUP. In the article from IBM above you can see that they are fitting the model to RUP.
Does someone has any practical explanation of the relation between these three interesting concepts.
Agile in an umbrella term for methods like XP, Scrum, Crystal, DSDM, FDD,... that share common principles. The Unified Process is a framework that can be used to describe a development process, RUP being one instantiation of UP based on Rational's tools. UP predates most Agile methods and may or may not be considered as Agile. What they have in common is that both Agile methods and UP are Iterative and Incremental Development (IID) methods.
RUP is a comprehensive iterative and incremental process template. You create a "Development Case" that informs you about what process components you will need in your instance of a development process. You then pull the required process components you need from RUP, like picking items from a menu.
"Agile" is an umbrella term that describes the set of processes that are based on the proposition that software development is a learning process rather than a defined process, and that most high-ceremony artifacts and practices impede the learning process.
SCRUM is a specific Agile project management process. It makes no provisions for how to actually design and develop the system being built.
Agile is an approach to software development:
(quoted from the Agile Alliance website)
What Is Agile Software Development?
In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.
Scrum and RUP are specific software development methods that can enable Agile software development. These methods (and others, such as XP) are not mutually exclusive, and can be combined in many ways to tailor an Agile process suitable for a particular project. This is a good article describing how these methods can be combined.
Agile and RUP grew separately, RUP on the foundation of UML, and now IBM is trying to catch up the agile wave cause there is no [more] big buzz on RUP.
Well, RUP is a "soup" of practices... You should customize it to drink your "own" soup... Otherwise it will "kill" your project...
In Agile project management, practices adapted from Complex Adaptive Dynamic Systems theory... It has a gentle touch with "human"... RUP does not say much about "peopleware" of project management...
Agile methods talk about "emergent" architecture... Where RUP is architecture-centric... Wants from you first establish stable architecture.
But you can apply RUP in an agile manner...Or you can barrow/steal many technical practices(soup incredents/recipes) from it...
They are both iterative models which seem similar, but both of them are vastly different. RUP is a framework for organizations and teams while Scrum is intended for a product team with stringent guidelines.
I'd suggest you read these:
SCRUM
RUP