de-DEen-GB
rss

Granikos Technology Blog

Bild Teamwork In den letzten Monaten sind mir während meiner Beratung in IT-Projekten immer öfter Menschen begegnet, die mit ihrer beruflichen Situation, ihrem Arbeitsalltag oder ihrem persönlichen Arbeitsumfeld unzufrieden sind. Diese Unzufriedenheit wirkte sich bei einigen bereits auf die körperliche Gesundheit aus. 

 

Woher kommt die Unzufriedenheit?

Die Unzufriedenheit im Berufsalltag hat unterschiedliche und oftmals sehr persönliche Gründe. Jeder von uns hat eigene Vorstellungen davon, was der Sinn von Arbeit sein soll und was uns im Inneren antreibt, einer Arbeit nachzugehen.

  • Stellen Sie sich schon morgens, vor dem Aufstehen, die Frage, warum Sie überhaupt aufstehen möchten?
  • Wandern die ersten Gedanken am Morgen zur Arbeit und zu unliebsamen Aufgaben oder unliebsamen Menschen, mit denen Sie gezwungenermaßen zusammenarbeiten müssen?
  • Müssen Sie sich gefühlt zum Gang zur Arbeit zwingen?  
  • Fühlen Sie sich an Ihrem Arbeitsplatz unterfordert?
  • Haben Sie das Gefühl, dass Ihr Arbeitgeber kein arbeitsfreundliches Umfeld anbietet?
  • Müssen Sie sich an Ihrem Arbeitsplatz ständig verstellen, um von Ihren Kollegen akzeptiert zu werden?
  • Verwenden Sie kräftezehrende Energie darauf, einem bestimmten Rollenbild zu entsprechen, dass nicht Sie sind?
  • Finden Sie an Ihrem Arbeitsplatz keine Person, die Sie unterstützt und mit Sie sich über Ihre beruflichen Sorgen austauschen können?
  • Verhindert Ihr Arbeitgeber aktiv Ihre persönliche Weiterentwicklung und verweigert Ihnen die Teilnahme an Fortbildungen?
  • Verspüren Sie einen ständigen Druck, den Erwartungen anderer, insbesondere von Vorgesetzten, gerecht werden zu müssen?

Diese Liste an Fragen zum Arbeitsumfeld kann beliebig erweitert werden.

Wenn Sie eine der Fragen für sich persönlich mit einem Ja beantworten können, ist die Zeit reif für eine Veränderung des beruflichen Umfeldes.  

Eine solche Veränderung erfordert immer eins: Mut.

 

Mut zur Veränderung

Eine berufliche Veränderung herbeizuführen, ist für Viele gar nicht so einfach. Solch eine Veränderung wirkt sich schließlich unmittelbar auf alle Bereiche des Lebens und auf das direkte familiäre Umfeld aus. Daher nehmen wir eine mögliche Veränderung des Arbeitsumfeldes oder sogar des Arbeitsverhältnisses als unlösbares Problem war und wählen stattdessen lieber den Weg des geringeren Widerstandes. Es erscheint uns einfacher, im aktuellen Status Quo zu verharren und die tägliche Unzufriedenheit zu ertragen. Der Weg zu einer beruflichen Veränderung erscheint als unüberwindbarer Kraftakt. 

Oftmals fehlt es uns auch einfach an Selbstvertrauen in die eigenen Fähigkeiten. Dazu besteht absolut kein Grund.

Für jeden ist der Weg und die notwendige Zeit zur beruflichen Veränderung unterschiedlich. Was jedoch für alle gleich ist, ist der Umstand, sich der eigenen Fähigkeiten und persönlichen beruflichen Interessen bewusst zu werden. Mit diesem Bewusstsein haben Sie direkt den Grundstein für Ihr Selbstvertrauen gelegt. Hierauf können Ihre Gedanken zur beruflichen Veränderung aufbauen. 

Eine berufliche Veränderung bedeutet nicht, dass Sie den gleichen Job nur bei einem anderen Arbeitgeber wahrnehmen sollen. Stellen Sie sich die Frage, was Sie besonders gut können, was Ihnen besonders viel Spaß macht und worin Sie Ihre ganz persönliche Erfüllung finden. Dies kann bedeutet, dass Sie in ein gänzlich anderes Berufsbild wechseln und so mehr Spaß an der Arbeit haben. Es kann auch bedeuten, dass Sie aus einer abhängigen Beschäftigung in die Selbstständigkeit wechseln und so in die Lage versetzt werden, Ihre Arbeitszeiten selbst einzuteilen.

Gerade im Bereich der IT und dem aktuellen Trend zu Cloud-Technologien stehen Ihre persönlichen Chancen gut. Allen Unternehmen fehlen spezialisierte Fachleute, um die sich schnell weiterentwickelnden Technologien zu verstehen, zu implementieren und zu betreiben. Die Unternehmen sind auf Sie angewiesen. Hier liegt Ihre Chance. 

Trauen Sie sich! Ihr Mut zur Veränderung wird belohnt.

 

Scheitern gehört dazu

Es wäre naiv zu denken, dass Scheitern unmöglich wäre. Aus persönlicher Erfahrung kann ich Ihnen sagen, dass Scheitern etwas Gutes ist. Leider wird Scheitern in unserem Kulturraum als etwas Negatives wahrgenommen. Lösen Sie sich von dieser negativen Assoziation, bevor Sie sich auf den Weg machen und versichern Sie sich des Rückhalts in Ihrem persönlichen Umfeld. 

Die wichtigste Erfahrung bei einem Scheitern ist, sich des Scheiterns bewusst zu werden und es nicht zu verdrängen. Je länger Sie es Verdrängen, desto größer wird der eigene emotionale Schmerz und, vielleicht schlimmer, der finanzielle Schaden. Hören Sie auf Meinungen aus dem familiären Umfeld und gönnen Sie sich das Recht, eine einmal getroffene Entscheidung abzuändern. 

Scheitern zuzulassen, ist eine Stärke.

 

Erfahrung

Natürlich liegt mein Themenschwerpunkt im Bereich der IT und hier besonders im Bereich der Microsoft-Technologien für On-Premises- und Cloudlösungen. 

Wenn Sie Fragen zur beruflichen Veränderung haben, ein Mentoring oder eine Begleitung bei der beruflichen Veränderung suchen, sprechen Sie mich an. Gerne teile ich meine persönlichen Erfahrungen aus der Zeit der abhängigen Beschäftigung und dem Wechsel in die Selbstständigkeit. Sie finden mich bei LinkedIn und Twitter.

Microsoft hilft Ihnen beim Erlernen neuer Fähigkeiten und bei der Erweiterung vorhandenen Wissen. Gerade erst wurde Microsoft Learn auf eine neue Plattform gebracht, um das Lernen noch einfacher zu ermöglichen. Mit dem Wandel zu cloudbasierten Produkten und Diensten wandeln sich auch die Anforderungen an das Wissen. In Zukunft ist ein Wissensspektrum, basierend auf einer Job-Rolle wichtiger als ein Wissenssilo zu einem einzelnen Produkt. Reines Produktwissen gehört der Vergangenheit ein.

Schauen Sie sich einmal die Übersicht der Lernangebote für die unterschiedlichen Job-Rollen bei Microsoft Learn in Ruhe an und überlegen Sie sich dann, wie Ihre berufliche Zukunft aussehen soll.

 

Links

 

 

 

Weiterlesen »

Microsoft Ignite 2018 LogoDie Microsoft Ignite 2018 Konferenz startet in einer Woche. 

Sie bietet auch in diesem Jahr wieder zahlreiche Breakout- und Theater-Sessions, um sich mit aktuellen und kommen Produkten und Funktionen auseinander zu setzen. Natürlich bietet die Konferenz auch den idealen Rahmen, um zu netzwerken.

Wenn Sie nicht  Vorort sein können, ist das nicht schlimm. Sie können die Aufzeichnungen der Sessions und die Inhalte in der Tech Community anschauen und herunterladen.

Meine Empfehlungen

Natürlich geht es nicht ohne Exchange Server. Die Veröffentlichung der dritten Version moderner Exchange Server steht bevor. Es wird sicher interessante Neuigkeiten und Funktionen rund um Exchange Server 2019 geben.

Exchange Server 

Neben Exchange Server ist Microsoft Teams ein großes Thema. Mit Microsoft Teams ermöglichen Sie eine sichere und effiziente Zusammenarbeit zwischen Mitarbeitern und externen Partnern.

Microsoft Teams

 

Links

 

Lassen Sie uns in Kontakt bleiben. Ich werde auf der Ignite Konferenz sein und freue mich, Sie dort persönlich kennenzulernen.

 

Weiterlesen »

The Program:

  • Implementation/migration of round about 25 instances with a Specific Laboratory Software, supporting ~30 laboratories world-wide
  • Reduce support cost per instance by standardization (for existing and added instances)
  • Development of a template ("foundation") containing common functionality which can be influenced by configuration. Integration of the foundation into all instances. Provide all instances in operation with the current version of the foundation on a regular basis.

 

The challenges:

  • 2-3 implementation projects parallel
    • Full scope not clear in the beginning
  • Increasing number of instances in operation
    • Regular update of foundation version necessary to keep them streamlined in order to reduce support cost
    • Requirements and bugfixes from systems in operation have to be included into foundation development process
  • Many and changing team members, part-time availability
    • Round about 12 team members (incl. development and support)
    • Changes due to boundary conditions triggered by external influences
    • 80% of people only part-time available for the program
  • High interdependency between ongoing projects and Systems which are already in in operation due to foundation development and shared resources.
  • Organization of communication process between projects and operation
  • Balancing individual business needs on one hand versus streamlined standard software on the other hand

 

Why agile:

  • Manage individual projects (introduction of new Software)
    • Decision for projects taken during run-time of the program
    • Sequence of projects changing
  • Manage user stories across projects (details not available at start of the program)
    • Each new project delivers a slightly differentiating list of user stories
    • Each instance in operation delivers additional stories
  • Manage process
    • Change process quite complex, adaptions to the process must be quickly implementable
       

 

The agile setup - how did we handle the challenges:

  • In fact the program has been setup before we got in touch with the standard Scrum process (See our blog: What is Scrum?). So we used other role names, but some of them have exactly - amongst others - the tasks defined for the standard Scrum roles.

 

Bild

 

Orange = Business, Green = IT

 

 

  • Scrum Master ~ Development Coordinator / Program QA
  • Product Owner
    • Program Manager
      • Overall Product Owner
    • Project Manager and Application Managers
      • Product Owner for particular instances -> Prioritization and review / testing of stories
      • Write User Stories
      • "Imitate" the end user for sprint releases
  • Global Change Manager
    • Scope definition for the foundation
    • Release management of the foundation
    • Organization of SME-Board
    • Prioritization
    • Product Owner for foundation
  • Architect
    • Knowledge of implementation framework
    • Sets up development guidelines and general implementation approach
    • Gives first estimation of requirements with a technical view
    • Better management of the large product backlog, due to technical understanding, prioritization estimation
  • Program QA
    • Set up of change management process for the program
    • Regular overall review of change management process
       
  • Additional meetings
    • Subject Matter Experts Board (SME) (bi-weekly)
      • Participants: Whole team
      • Reviews the requirements from a technical and functional point of view
      • Gives implementation recommendations as decision memo for the CAB (Change Advisory Board)
      • Discusses additional technical issues
    • Process Review Meeting (quarterly in the beginning, currently twice a year)
      • Participants: Whole team 

 

The experiences:

  • User stories: Definition of user stories dependent on target group, developing a template of user story definition fitting for all team member in different roles, with different views and different backgrounds is a time consuming task
  • Testing: Developing awareness for testing right after delivering of implemented user story took also lot of time and patience 
  • Definition of project related sprint releases is useful to get quick feedback and reduces the effort for project managers (not every project manager has to test each increment)
  • A clear definition of product ownership incl. responsibility for successful product delivery is important for a successful project

 

This was the last part of our small Series about Agile Project Management

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.

 

 

Weiterlesen »

Agile Project Management in real Life

 

The Project:

  • Development of a new web shop
  • Bring this web shop to a new platform to enable further enhancements (old platform was outdated)

 

The challenges:

  • Very high amount of complex requirements
  • Dependencies to other projects and an overarching IT Strategy Program
  • Special regional processes and requirements
  • New, unknown platform and framework

 

Why agile:

  • Manage high amount of requirements (incomplete list at start of the project)
    • Start by collecting all requirements on a very high level
    • Refine requirements during the project in order to save time by not writing every detail at the beginning of the project
  • Able to react to decisions from the IT Strategy program and/or other projects
    • The Project had to start earlier than the program, so some program decisions were not made at the beginning of the project
  • No clear "customer" as it was an internal project, but end-users are external customers of the company

 

The agile setup - how did we handle the challenges:

  • Besides the standard Scrum roles (See our last blog entry: What is Scrum?), additional roles were part of the project

 

image

Orange = Business, Green = IT

 

  • Cross Regional Working Team = Group of colleagues from different Departments act as "customers"
    • Write User Stories
    • Review product and give feedback
    • "Imitate" the end user
  • IT Process Designer as an IT counterpart to the Business Product Owner
    • More technical knowledge
    • Understands and communicates technical problems
    • Also has a very good knowledge about the business processes
    • Better management of the big product backlog, due to technical understanding, prioritization estimation
  • Additional Role "Solution Architect"
    • Knowledge of new implementation framework
    • Sets up development guidelines and general implementation approach
    • Gives first estimation of requirements
    • Better management of the large product backlog, due to technical understanding, prioritization estimation

 

  • Additional meetings to manage backlog
    • Sprint Planning Preparation
      • Participants: Solution Architect, IT Process Designer and Product Owner
      • Prepare Sprint Planning, define Sprint goal and set a rough scope for the next Sprint
    • Backlog Refinement
      • Participants: Development Team, Solution Architect and IT Process Designer
      • Review high prioritized stories and refine them to a state where they can be implemented
      • Add details to stories and split them up into multiple stories if needed

 

The experiences:

  • First version of user stories were very unspecific and way too complex to be implemented straight away
    • It was clear from the beginning that stories have to be refined (see "Challenges of the project" - Point 1) - but the effort to get the stories to a point where they can actually be implemented was underestimated
    • Project progress became unclear because the team did not work on actual business user stories, because they were too unspecific and complex, but transferred them into technical stories
  • Stories had to be split up multiple times, overall structure of story clustering and complexity changed multiple times
  • Tools such as JIRA were great to track and manage the backlog and to document and share knowledge within the project team
  • Not everyone has had agile experience
    • Roles were not fully clarified at the beginning, therefore more communication between the roles was needed, to make sure everyone understood his responsibility
    • During the project each role developed and grew based on the experience
    • The roles later on took over responsibility and made decisions where needed

 

Despite the difficulties especially at the beginning of the project, it is still very well in time. This is caused by the fact that the team always kept working and the project was never unable to go on. Due to the agile nature of the project in time communication and transparency were possible!

 

This was the third part of our small Series about Agile Project Management. Look out for the next part which we are going to publish soon called "Agile Project Management – Agile on the next Level - Program Management"

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.

 

 

Weiterlesen »

SCRUM as a method in Agile Project Management

 

In the preparation of this article, we discussed several ideas, how to introduce Scrum to you. In search of inspirations we have found the introduction video from the Scrum alliance.

In the end, this is a pretty short 80-seconds introduction to Scrum, which we would like to show to you, instead of reinventing the wheel again.

 

 

In addition to the video we would like to share more information:

 

 

Expectations to Scrum:

 

Scrum is very good when it comes to establishing agile methods into an organization. By providing a simple approach it can easily be picked up and enhanced. Also Scrum is very well known and there are lots of experienced Scrum Coaches in the outside world of Covestro.

 

Scrum is a framework which provides a basis of 3 roles, 4 activities and 3 artifacts, which will now be explained in detail.

Each Scrum implementation is different though. Depending on the project or the organization there will be additional roles or activities. Scrum focuses on communication and collaboration by discussing requirements and short feedback cycles, which is the most important thing to keep in mind.

 

In the following we want to explain the different roles, activities and artifacts. Furthermore we want to provide you a check list what you have to prepare for your first Scrum project.

 

 

Terms:

User Stories

A simple method to describe requirements, by a user's perspective, with only one or a few sentences. Usually a user story consist of Who? What? And Why?

e.g.: "As a user I want to be able to back up my data in order to recover it in case of an error."

User stories are constantly refined and extended during the project. They are the basis for discussion about the features. This will help to get a clear understanding of the requirements.

Sprint

An iteration of Scrum which is usually between 1 and 4 weeks long. Or in other words: This is the timeframe, in which work is planned continuously. Once the duration is set it should not be changed during the project though.

Artifacts

Artifacts provide information about the product, the requirement and the progress. The scrum team permanently works with the artifacts. For instance, an artifact is the list of requirements which are known so far.

Activities

Activities are mostly meetings which are part of each sprint. (The sprint itself can be seen as an activity too) By discussing and/or working with the artifacts during the activities, the project progress and obstacles become transparent.

Definition of Done

A project specific agreement which defines when a user story is completed.

 

Roles:

  • Product Owner
    • Manages the product backlog and overviews all user stories
    • Drives the product vision
    • Represents the project stakeholders and gathers requirements and feedback from them
  • Scrum Master
    • Establishes the Scrum process and makes sure that the process is followed
    • "Coach" of the Dev. Team
  • Development Team
    • Self-organized and cross functional (tester, designer, architect, developer)
    • Realizes the user stories

 

Additional involved persons:

  • Stakeholder
    • Involved in creating the requirements
    • Give feedback about the product increment
    • Examples: User, Application Owner, Application Manager, etc.

 

Activities:

  • Daily Scrum
    • Dev. Team + Scrum Master
    • Daily stand up meeting: What did I do yesterday? What am I doing today? Anything that hinders my work?
  • Sprint Planning
    • Product Owner + Dev. Team + Scrum Master
    • "Sprint Kickoff" - once per Sprint
    • Define Sprint scope, clarify last questions and estimate effort
    • Outcome = Sprint Backlog
  • Sprint Review
    • Product Owner + Dev. Team + Scrum Master
    • Review product increment with stakeholders and collect their feedback
    • At the end of each Sprint
  • Sprint Retrospective
    • Scrum Master + Dev. Team
    • Review the Scrum process
    • Identify optimizations for the Scrum Process and define tasks to realize the optimizations
    • At the end of each Sprint

 

Artifacts:

  • Product Backlog
    • List of all requirements to the product, which are known so far
    • Prioritized and refined by the Product Owner
    • Requirements can be changed, added or removed from the backlog
    • Single source of requirements for changes to the product
  • Sprint Backlog
    • List of all requirements which are planned to be realized in the next sprint
    • Cannot be changed during the sprint
    • Managed by the Dev. Team once the sprint started
  • Product Increment
    • Result of each sprint
    • Can potentially be used by the customer

 

When you want to start your first Scrum project there are several tasks which should be completed upfront:

 

  • Define your Scrum team (Product Owner, Scrum Master, Development Team)
  • Explain Scrum to the project team and especially explain the roles
  • Identify Stakeholders and involve them into the project setup
  • Establish an agile mindset, explain reasons for Scrum and the agile approach, make sure the approach is understood and accepted
    • The initial set up is not carved in stone, it will evolve during the project together with the Scrum experience of the team mainly based on the Sprint Retrospective
  • Decide on a Sprint duration
  • Set up the meetings, reserve rooms and plan them ahead ideally for the whole project time
  • If needed design additional roles/activities but do not overcomplicate the process

 

 

This was the second part of our small Series about Agile Project Management. Look out for the next part which we are going to publish soon called "Agile Project Management – Agile Project Management in real Life"

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.

 

 

Weiterlesen »